btw, one of the reasons why I would like to (some day) rewrite the DBXTalk Driver getting rid of opendbx is because it answers always strings (char*) [1], which at the time needs to be parsed too... slowing a lot the process. but well, since it is not an easy task, it will be delayed indefinitely, I think (until someone really needs it) :)
cheers, Esteban [1] See: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_field_value On Jul 30, 2013, at 5:17 AM, Yanni Chiu <ya...@rogers.com> wrote: > On 29/07/13 7:08 PM, Sven Van Caekenberghe wrote: >> >> The explanation for the slowdown must be in the PgV2 driver. > > The PgV2 protocol is described at: > http://www.postgresql.org/docs/7.1/static/protocol-message-formats.html > > Have a glance at the "AsciiRow" and "BinaryRow" message formats. The driver > reads the data off the socket, parsing the the data, as described as > described by the message format. With the V2 protocol design, you have to > read the result row, one field at a time. > > IIUC, in the newer V3? protocol, the AsciiRow/BinaryRow message is replaced > by a DataRow message. The DataRow message has the message size included, > which could allow the driver to read the entire set of fields for one data > row, using a single socket read (or a few buffer sized reads). > > I recall seeing an experimental V3 protocol implementation, a few years back > - sorry, no links handy. It would be nice to see some benchmarks. > > Hope that helps. >
