Re: Large # of rows in query extremely slow, not using index - Mailing list pgsql-performance

From Tom Lane
Subject Re: Large # of rows in query extremely slow, not using index
Date
Msg-id 28432.1095126554@sss.pgh.pa.us
Whole thread Raw
In response to Re: Large # of rows in query extremely slow, not using index  (Stephen Crowley <stephen.crowley@gmail.com>)
Responses Re: Large # of rows in query extremely slow, not using index  (Stephen Crowley <stephen.crowley@gmail.com>)
List pgsql-performance
Stephen Crowley <stephen.crowley@gmail.com> writes:
> On Mon, 13 Sep 2004 21:11:07 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Stephen Crowley <stephen.crowley@gmail.com> writes:
>>> Does postgres cache the entire result set before it begins returning
>>> data to the client?
>>
>> The backend doesn't, but libpq does, and I think JDBC does too.

> That is incredible. Why would libpq do such a thing?

Because the API it presents doesn't allow for the possibility of query
failure after having given you back a PGresult: either you have the
whole result available with no further worries, or you don't.
If you think it's "incredible", let's see you design an equally
easy-to-use API that doesn't make this assumption.

(Now having said that, I would have no objection to someone extending
libpq to offer an alternative streaming API for query results.  It
hasn't got to the top of anyone's to-do list though ... and I'm
unconvinced that psql could use it if it did exist.)

            regards, tom lane

pgsql-performance by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Next
From: Tom Lane
Date:
Subject: Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options