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
|
Список | 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 по дате отправления: