Re: Incremental results from libpq

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-interfaces(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Scott Lamb" <slamb(at)slamb(dot)org>
Subject: Re: Incremental results from libpq
Date: 2005-11-16 09:57:15
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE6C7BD8@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

> > The main reason why libpq does what it does is that this
> way we do not
> > have to expose in the API the notion of a command that
> fails part way
> > through.
>
> I'm at LinuxWorld Frankfurt and one of the Trolltech guys
> came over to talk to me about this. He opined that it would
> be beneficial for their purpose (in certain cases) if the
> server would first compute the entire result set and keep it
> in the server memory (thus eliminating potential errors of the 1/x
> kind) and then ship it to the client in a way that the client
> would be able to fetch it piecewise. Then, the client
> application could build the display incrementally while the
> rest of the result set travels over the (slow) link.
> Does that make sense?

I think it does :-)

It would also remove the requirement to keep the whole resultset in
memory on the client. You'd still nede the RAM on the server, but no
need to duplicate it on the client. (And no need to store it *twice* if
your clietn happens to be running on the db server, in which case the
slow network point doesn't apply)

//Magnus

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2005-11-16 14:24:24 Re: Incremental results from libpq
Previous Message Peter Eisentraut 2005-11-16 09:34:58 Re: Incremental results from libpq