> Yeah, but they had to back-off from that plan, and AFAIK it only uses
> libpq for the auth stuff and then switch to dealing with the protocol
> directly.
>
> I don't know what the reasoning was though :-) I guess Joshua would
> know. I'm not involved in that project. I only know that recently a
> user posted some measurements showing that ODBCng was way slower that
> psqlODBC, and it was discovered that it was using v3 Prepare/Bind/
> Execute, which was problematic performance-wise due to the planner
> issues with that. So AFAIK it currently parses the statements
> internally before passing them to the server.
That is correct, we were using PostgreSQL server side prepare which has
shown to be ridiculously slow. So we moved to client side prepare and
ODBCng now moves very, very quickly.
You can see results here:
http://projects.commandprompt.com/public/odbcng/wiki/Performance
As in, it moves quickly enough to compete with other bindings such as
DBD::Pg.
One of the libpq features we wanted to avoid was the receiving of all
results on the server before sending to the client. With ODBCng we have
a buffering option that will receive all results over the wire directly.
This can increase performance quite a bit in specific circumstances but
also has the downside of using more memory on the ODBC client.
We also have a security through obscurity feature as described here:
http://projects.commandprompt.com/public/odbcng/wiki/PatternMatch
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate