Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
Дата
Msg-id CA+TgmoYXbN524pY=Fyfu2riWAcrynAN_2eEc9f4bP6y+XmVtmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs  (Jakub Wartak <jakub.wartak@enterprisedb.com>)
Список pgsql-hackers
On Wed, Jan 4, 2023 at 11:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As you well know, psql's FETCH_COUNT mechanism is far older than
> single-row mode.  I don't think anyone's tried to transpose it
> onto that.  I agree that it seems like a good idea to try.
> There will be more per-row overhead, but the increase in flexibility
> is likely to justify that.

Yeah, I was vaguely worried that there might be more per-row overhead,
not that I know a lot about this topic. I wonder if there's a way to
mitigate that. I'm a bit suspicious that what we want here is really
more of an incremental mode than a single-row mode i.e. yeah, you want
to fetch rows without materializing the whole result, but maybe not in
batches of exactly size one.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jacob Champion
Дата:
Сообщение: Re: [PATCH] CF app: add "Returned: Needs more interest"
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: pgsql: Delay commit status checks until freezing executes.