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-02 16:50:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> Updated patches are attached.

I started to look through this, and almost immediately noted

- <sect1 id="libpq-single-row-mode">
- <title>Retrieving Query Results Row-by-Row</title>
+ <sect1 id="libpq-chunked-results-modes">
+ <title>Retrieving Query Results in chunks</title>

This is a bit problematic, because changing the sect1 ID will
change the page's URL, eg

Aside from possibly breaking people's bookmarks, I'm pretty sure this
will cause the web docs framework to not recognize any cross-version
commonality of the page. How ugly would it be if we left the ID
alone? Another idea could be to leave the whole page alone and add
a new <sect1> for chunked mode.

But ... TBH I'm not convinced that we need the chunked mode at all.
We explicitly rejected that idea back when single-row mode was
designed, see around here:

and I'm still very skeptical that there's much win to be had.
I do not buy that psql's FETCH_COUNT mode is a sufficient reason
to add it. FETCH_COUNT mode is not something you'd use
non-interactively, and there is enough overhead elsewhere in psql
(notably in result-set formatting) that it doesn't seem worth
micro-optimizing the part about fetching from libpq.

(I see that there was some discussion in that old thread about
micro-optimizing single-row mode internally to libpq by making
PGresult creation cheaper, which I don't think anyone ever got
back to doing. Maybe we should resurrect that.)

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-02 16:58:18 Re: On disable_cost
Previous Message Robert Haas 2024-04-02 16:26:27 Re: On disable_cost