Re: Report buffer access strategies in EXPLAIN

Hi,

On Fri, Nov 06, 2026 at 11:14:57AM +0900, Michael Paquier wrote:
> On Thu, Nov 05, 2026 at 12:17:42PM +0000, Bertrand Drouvot wrote:
> > Right, that's why the text refers specifically to the 256KB target. Do you
> > mean that the L2 cache rationale should be dropped now that it does not
> > necessarily apply to the resulting ring size?
>
> v4 still has the same text:

Yes, your comment was not clear to me, that's why I asked the above question
before proposing changes.

> +For bulk reads, the requested ring size is at least 256KB. The 256KB target is
> +small enough to fit in L2 cache, which makes transferring pages from OS cache
> +to shared buffer cache efficient.
>
> L2 caches can be larger than 256kB, so having a larger size could
> still be effective. The current wording sounds slightly confusing to
> me here due to that. But perhaps your wording is fine enough. I
> suspect that Andres and other folks involved in this area of the code
> would have comments about these parts. Better to wait for inputs from
> them.

I see what you mean now.

I did some archeology. This wording was added in d526575f893c when L2 larger
than 256kB was already a thing (but the requested ring size did not grow beyond
256kB at the time).

Maybe we could add something like?

"Larger rings may retain this benefit on systems with larger L2 caches"

That said, let's wait for Andres and others as you suggest.

> > That makes sense. I've listed the commands under each applicable strategy. Note
> > that some appear in both lists: for example, CREATE DATABASE uses bulkread for
> > the source and bulkwrite for the destination. I did not go as far as explaining
> > why in the glossary.
>
> The checksumming part is missing for checksums where BAS_VACUUM is in
> use.
>
> v4-0002 seems mostly OK here, with your previous adjustments included.
>
> + <literal>vacuum</literal>: I/O operations performed using the
> + <literal>vacuum</literal>
> + <glossterm linkend="glossary-buffer-access-strategy">buffer access
> + strategy</glossterm>

Makes sense, will do.

> In v4-0003, too many vacuum references perhaps? This is the same as
> my previous comment when I have looked at the v3 series. I'm
> wondering if you should make it simpler, by the addition of linkend
> once within parenthesis like a simpler "(see also <linkend>BAS</>)",
> with a set of <literal>s for the follow-up references.

Good idea, will do.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com