| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Crowley <stephen(dot)crowley(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Large # of rows in query extremely slow, not using index |
| Date: | 2004-09-14 01:49:14 |
| Message-ID: | 28432.1095126554@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Stephen Crowley <stephen(dot)crowley(at)gmail(dot)com> writes:
> On Mon, 13 Sep 2004 21:11:07 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Stephen Crowley <stephen(dot)crowley(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-09-14 02:00:59 | Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options |
| Previous Message | Gaetano Mendola | 2004-09-14 01:39:35 | Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options |