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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
Subject: Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
Date: 2024-04-07 00:53:56
Message-ID: 2631427.1712451236@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So what was really bothering me about this patchset was that I
didn't think marginal performance gains were a sufficient reason
to put a whole different operating mode into libpq. However,
I've reconsidered after realizing that implementing FETCH_COUNT
atop traditional single-row mode would require either merging
single-row results into a bigger PGresult or persuading psql's
results-printing code to accept an array of PGresults not just
one. Either of those would be expensive and ugly, not to mention
needing chunks of code we don't have today.

Also, it doesn't really need to be a whole different operating mode.
There's no reason that single-row mode shouldn't be exactly equivalent
to chunk mode with chunk size 1, except for the result status code.
(We've got to keep PGRES_SINGLE_TUPLE for the old behavior, but
using that for a chunked result would be too confusing.)

So I whacked the patch around till I liked it better, and pushed it.
I hope my haste will not come back to bite me, but we are getting
pretty hard up against the feature-freeze deadline.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-07 01:25:11 Re: Streaming read-ready sequential scan code
Previous Message Andres Freund 2024-04-07 00:49:13 Re: Cluster::restart dumping logs when stop fails