Re: [HACKERS] Another nasty cache problem
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Another nasty cache problem |
Дата | |
Msg-id | 1812.949646025@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another nasty cache problem (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>) |
Список | pgsql-hackers |
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes: >> No ... portals are a backend concept ... > Since when? > According to the old doco you do... > select portal XX * from table_name where ...; > fetch 20 into XX. That still works if you spell it in the SQL-approved way, DECLARE CURSOR followed by FETCH. > If the PQexec() is called with "fetch 20" at a time > wouldn't this mean that you wouldn't exhaust front-end > memory with a big query? Sure, and that's how you work around the problem. Nonetheless this requires the user to structure his queries to avoid sucking up a lot of data in a single query. If the user doesn't have any particular reason to need random access into a query result, it'd be nicer to be able to read the result in a streaming fashion without buffering it anywhere *or* making arbitrary divisions in it. In any case, psql doesn't (and IMHO shouldn't) convert a SELECT into a series of FETCHes for you. regards, tom lane
В списке pgsql-hackers по дате отправления: