与旧的 ODBC 提供程序相比，PostgreSQL 的 .NET 提供程序运行缓慢
与 ODBC 提供程序相比，为什么 NPGSQL .NET 数据提供程序较慢？我没有尝试过 NPGSQL 2.0，但我确实使用过 NPGSQL 1.0。速度非常慢。
您对 NPGSQL 2.0 有何体验？
Why is it that the NPGSQL .NET Data Provider is slow when compared with the ODBC Provider? I have not tried NPGSQL 2.0 but I did worked with NPGSQL 1.0. It was very slow.
What are your experiences with NPGSQL 2.0?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 2.0.1 没有任何问题，与 ODBC 相比，速度没有明显差异（我听说 Npgsql 1.0 不太好，但没有使用它）。在 Windows 窗体和 WPF 应用程序中将其与 ADO .Net 一起使用没有问题。这样做时的一个建议是：采用 ADO 使用的“断开连接”范例更为可靠，即：打开连接、执行某些操作、关闭连接，而不是尝试在应用程序的生命周期中使用单个打开的连接。 我还
发现这个页面比 pgFoundry 更好： http://npgsql.projects.postgresql.org/
Have had no problems with 2.0.1 and no noticeable difference in speed as opposed to ODBC (I heard Npgsql 1.0 wasnt great but havent used it). Have been using it with ADO .Net in Windows Forms and WPF apps no problem. One reccomendation when doing so: it is more robust to adopt the 'disconnected' paradigm used by ADO which is: Open a connection, do something, close a connection, rather than trying to use a single open connection for the lifetime of your app..
Also I find better to use this page than the pgFoundry one: http://npgsql.projects.postgresql.org/
我尝试过 npgsql 2.0，但性能仍然没有变化。它的工作速度非常非常慢。我使用的解决方案没有 ado.net。我正在使用executereader，然后将此数据解析为一个对象。 ...我认为 npgsql 不能很好地解析具有大量数据的文本列，因为在某些情况下，我注意到当结果不太大并且数据不包含大数据时，性能很好文本栏。
i have tried with npgsql 2.0, and still i have no changes in performance. it works very very slow. the solution i am using is without ado.net. i am using executereader and then parse this data into an object. ... i thing that npgsql doesn't parse very well text columns with large amount of data, because in some cases i have noticed that the performance is good, when the result isn't too large and the data doesn't contain large text columns.
值得注意的是，2008年4月7日发布的2.0beta3在这方面做出了重大改变。方法的变化非常显着，因此有必要在连接字符串中添加向后兼容标志，因为某些代码依赖于旧方法的副作用。这也意味着两者之间的差异已记录。
It's worth noting that a significant change in this regard was made with 2.0beta3 which was released on 2008-04-07. The change in approach was significant enough that it was necessary to add a backwards-compatibility flag in the connectionstring as some code depended on side-effects of the old approach. This also means that the difference between the two is documented.