From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Georgios <gkokolatos(at)protonmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: index prefetching |
Date: | 2025-07-16 14:29:36 |
Message-ID: | CAH2-Wz=tFoZCZM5zgvsbV0=ArJwu2kHvPU7KD431fhZd5hgnDw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 16, 2025 at 10:20 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> The read stream can only return blocks generated by the "next" callback.
> When we return the block for the last item on a leaf page, we can only
> return "InvalidBlockNumber" which means "no more blocks in the stream".
> And once we advance to the next leaf, we say "hey, there's more blocks".
> Which is what read_stream_reset() does.
>
> It's a bit like what rescan does.
That sounds weird.
> In an ideal world we'd have a function that'd "pause" the stream,
> without resetting the distance etc. But we don't have that, and the
> reset thing was suggested to me as a workaround.
Does the "complex" patch require a similar workaround? Why or why not?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2025-07-16 14:36:34 | Re: libpq: Process buffered SSL read bytes to support records >8kB on async API |
Previous Message | Peter Geoghegan | 2025-07-16 14:27:25 | Re: index prefetching |