> 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
