Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
| От | Jakub Wartak | 
|---|---|
| Тема | Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs | 
| Дата | |
| Msg-id | CAKZiRmyDoVYa3d4yM-U7h7iX+CghHzHN6x-skM4mALR4EYJFMg@mail.gmail.com обсуждение исходный текст | 
| Ответ на | Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs (Robert Haas <robertmhaas@gmail.com>) | 
| Список | pgsql-hackers | 
On Wed, Jan 4, 2023 at 6:38 PM Robert Haas <robertmhaas@gmail.com> wrote: > > 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. Given the low importance and very low priority of this, how about adding it as a TODO wiki item then and maybe adding just some warning instead? I've intentionally avoided parsing grammar and regexp so it's not perfect (not that I do care about this too much either, as web crawlers already have indexed this $thread). BTW I've found two threads if know what are you looking for [1][2] -Jakub Wartak. [1] - https://www.postgresql.org/message-id/flat/a0a854b6-563c-4a11-bf1c-d6c6f924004d%40manitou-mail.org [2] - https://www.postgresql.org/message-id/flat/1274761885.4261.233.camel%40minidragon
Вложения
В списке pgsql-hackers по дате отправления: