| From: | Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshke(at)double(dot)cloud>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: Use fadvise in wal replay |
| Date: | 2022-06-21 10:20:14 |
| Message-ID: | AM8PR07MB8248DAA91E79BE3B158A1ACFF6B39@AM8PR07MB8248.eurprd07.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> > On 21 Jun 2022, at 12:35, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> >
>> > I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
>> > help your case?
>>
>> AFAICS recovery_prefetch tries to prefetch main fork, but does not try to
>> prefetch WAL itself before reading it. Kirill is trying to solve the problem of
>> reading WAL segments that are our of OS page cache.
It seems that it is always by default set to 128 (kB) by default, another thing is that having (default) 16MB WAL segments might also hinder the readahead heuristics compared to having configured the bigger WAL segment size.
Maybe the important question is why would be readahead mechanism be disabled in the first place via /sys | blockdev ?
-J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2022-06-21 10:24:01 | Re: Use fadvise in wal replay |
| Previous Message | Aleksander Alekseev | 2022-06-21 09:56:21 | Re: Make COPY extendable in order to support Parquet and other formats |