Re: Protocol 3, Execute, maxrows to return, impact?

On Mon, Jul 28, 2008 at 3:36 PM, Andrew Garner
<andrew(dot)b(dot)garner(at)gmail(dot)com> wrote:
>
> On 7/27/08, Stephen R. van den Berg <srb(at)cuci(dot)nl> wrote:
>>
>> Stephen R. van den Berg wrote:
>> >My Pike drivers now support multiple simultaneous portals and
>> >automatic streaming by presending overlapping Execute statements with
>> >a dynamically adapted fetchlimit calculated per select as the query
>> >progresses.
>>
>>
>> They also support COPY now.
>>
>> The driver beats libpq in speed by about 62%.
>> The memory consumption is on demand, by row, and not the whole result set.
>> Transport to and from the query is in binary and dynamically determined
>> per datatype, no quoting necessary.
>>
>> Anyone interested in taking a peek at the (GPL copyright) driver, I
>> temporarily put up a small package which contains the working driver
>> in Pike at:
>>
>> http://admin.cuci.nl/psgsql.pike.tar.gz
>
> I'd love to take a look at the code, but the link seems to be 404'd at the
> moment.
>

Hi, I'd love to take a look at the code too. I'm the lead developer of
Npgsql a .Net data provider for postgresql which implements the
protocol 2 and 3. And have been following this thread so I could get
more info about protocol implementation internals so we could use in
our .net implementation. Currently we don't support multiple
resultsets yet.

Also, I'd like to get some ideas about how to optimize throughput. You
said you got a huge improvement compared to libpq. I think you may
implement some nice ideas which we could use to optimize Npgsql.

I'm also getting 404 error when trying to download the code.

--
Regards,

Francisco Figueiredo Jr.
http://fxjr.blogspot.com
http://www.npgsql.org