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.
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 |