Re: Large # of rows in query extremely slow, not using index
От | Tom Lane |
---|---|
Тема | Re: Large # of rows in query extremely slow, not using index |
Дата | |
Msg-id | 28432.1095126554@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Large # of rows in query extremely slow, not using index (Stephen Crowley <stephen.crowley@gmail.com>) |
Ответы |
Re: Large # of rows in query extremely slow, not using index
|
Список | 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 по дате отправления: