| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| 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 11:24:44 |
| Message-ID: | CAA4eK1K1OnvbL_-oy7yXFmhWv=wv+Pg6LKE1xSd541+hfewZZw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 21, 2022 at 3:18 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> > 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.
>
Okay, but normally the WAL written by walreceiver is read by the
startup process soon after it's written as indicated in code comments
(get_sync_bit()). So, what is causing the delay here which makes the
startup process perform physical reads?
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2022-06-21 12:11:12 | Re: Use fadvise in wal replay |
| Previous Message | Bharath Rupireddy | 2022-06-21 11:03:50 | Re: Use fadvise in wal replay |