Re: BAS_BULKREAD vs read stream

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: BAS_BULKREAD vs read stream
Date: 2025-04-08 09:00:42
Message-ID: CAKZiRmwQchMK_97KcqSQob0aCax1kCLXE9n3vio_SR5nQBq-+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 6, 2025 at 10:15 PM Andres Freund <andres(at)anarazel(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuya Watari 2025-04-08 09:04:16 Re: [PoC] Reducing planning time when tables have many partitions
Previous Message Ilia Evdokimov 2025-04-08 08:56:53 Re: track generic and custom plans in pg_stat_statements