| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Report buffer access strategies in EXPLAIN |
| Date: | 2026-11-12 13:15:34 |
| Message-ID: | avW79icT2yqW50g5@bdtpg |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 06, 2026 at 08:14:31AM +0000, Bertrand Drouvot wrote:
> 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"
PFA v5 using the wording proposed above and addressing your other comments. It
also includes the changes discussed with Lukas in [1]. I kept 0008 for now,
though we may still decide to drop it.
[1]: https://postgr.es/m/au2o6TU%2Bqc61264l%40bdtpg
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Update-buffer-strategy-descriptions-in-the-buffer.patch | text/x-diff | 4.9 KB |
| v5-0002-Describe-buffer-access-strategy-types-in-the-glos.patch | text/x-diff | 5.0 KB |
| v5-0003-Clarify-buffer-access-strategies-in-pg_stat_io-do.patch | text/x-diff | 4.7 KB |
| v5-0004-Refactor-table-scan-instrumentation-lookup.patch | text/x-diff | 5.9 KB |
| v5-0005-Add-buffer-access-strategies-to-table-scan-instru.patch | text/x-diff | 15.5 KB |
| v5-0006-Add-table-scan-instrumentation-for-sample-and-TID.patch | text/x-diff | 20.8 KB |
| v5-0007-Report-buffer-access-strategies-for-table-scans-i.patch | text/x-diff | 19.1 KB |
| v5-0008-Report-buffer-access-strategies-for-index-scans-i.patch | text/x-diff | 24.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kirill Reshke | 2026-11-12 13:21:25 | Re: amcheck: add index-all-keys-match verification for B-Tree |
| Previous Message | Greg Burd | 2026-11-12 13:10:11 | Re: Tepid: selective index updates for heap relations |