| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs |
| Date: | 2023-01-04 17:38:17 |
| Message-ID: | CA+TgmoYXbN524pY=Fyfu2riWAcrynAN_2eEc9f4bP6y+XmVtmg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 4, 2023 at 11:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2023-01-04 17:59:37 | Re: pgsql: Delay commit status checks until freezing executes. |
| Previous Message | Jacob Champion | 2023-01-04 17:33:35 | Re: [PATCH] CF app: add "Returned: Needs more interest" |