Re: postgresql protocol v3

If I understand it correctly, we get v3 in the C interface for free and 
that's what we're running now just by linking in (uffi'ing and loading 
, rather) the proper version of libpq. Hmm... Of course this means that 
my prepared statement stuff will break if somebody tries to use libpq 
that predates 7.4. I hadn't thought about that yet. Is this a problem? 
Do we need to fork this too?

I'm curious what's causing the performance degradation. I'm still not 
convinced I understand this stuff properly, but it looks like my 
initial impression of how this stuff works is wrong. We should really 
call these something like postgresql-libpq and postgresql-cl-fe or some 
such where the libpq one is what's now known as postgresql and the 
cl-fe is the socket one. It looks like they both use sockets to talk to 
the backend, but that the postgres/libpq version just calls libpq which 
does all the socket stuff and that that the postgres-socket/cl-fe is an 
alternative "front-end". It seems like it should be possible to write a 
cl front-end that performs roughly as well as libpq. Maybe we can dig 
up some benchmark data and try to fix this up if there's sufficient 
interest. But, if performance is at all an issue, I would strongly 
suggest using prepared statements.

Cyrus

On Dec 4, 2004, at 10:24 AM, Kevin Rosenberg wrote:

> Cyrus Harmon wrote:
>> Furthermore, postgresql-v8 supports per column binary results with the
>> extended query protocol, which would be nice.
>
> Will protocol 3 be supported both on the socket interface and the C
> interface. In some benchmarks, I've found the C interface to be
> several times faster than the network interface.
>
> Kevin