Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>,
Jakub Wartak <jakub.wartak@enterprisedb.com>
Date: 2024-04-07T00:53:56Z
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
Commits
-
Further review for re-implementation of psql's FETCH_COUNT feature.
- c21d4c416ad6 17.0 landed
-
Re-implement psql's FETCH_COUNT feature atop libpq's chunked mode.
- 90f5178211cd 17.0 landed
-
Support retrieval of results in chunks with libpq.
- 4643a2b265e9 17.0 landed
-
Attempt to fix newly added Memoize regression test
- a3a836fb5e51 17.0 cited