Re: BAS_BULKREAD vs read stream - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: BAS_BULKREAD vs read stream
Date
Msg-id CAKZiRmwQchMK_97KcqSQob0aCax1kCLXE9n3vio_SR5nQBq-+A@mail.gmail.com
Whole thread Raw
In response to BAS_BULKREAD vs read stream  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, Apr 6, 2025 at 10:15 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
[..]
> The obvious solution to that would be to increase BAS_BULKREAD substantially
> above 256kB.
>
> For quite a while was worried about increasing the size, because somewhere (I
> couldn't find it while writing this email, will add the reference once I
> refound it) we have a comment explaining that a small size was chosen because
> it helps with CPU cache efficiency.

Hi, FWIW, I was trying to understand the scope of this change and
GetAccessStrategy() actually asks to go to
src/backend/storage/buffer/README which explains the logic behind the
old (pre-commit now) rationale and value. It says
```
For sequential scans, a 256KB ring is used. That's small enough to fit in L2
cache, which makes transferring pages from OS cache to shared buffer cache
efficient.
```

-J.



pgsql-hackers by date:

Previous
From: Ilia Evdokimov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements
Next
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions