Re: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id CA+hUKGL=WyaYd-Js3HNq7BYoNoDX8ej1Rw3OfW2UDfshf4d9VA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Thu, Feb 4, 2021 at 1:40 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> With master, it'd take ~16000 seconds to catch up. I don't have the
> exact number, because I got tired of waiting, but the estimate is likely
> accurate (judging by other tests and how regular the progress is).
>
> With WAL prefetching enabled (I bumped up the buffer to 2MB, and
> prefetch limit to 500, but that was mostly just arbitrary choice), it
> finishes in ~3200 seconds. This includes replication of the pgbench
> initialization, which took ~200 seconds and where prefetching is mostly
> useless. That's a damn pretty improvement, I guess!

Hi Tomas,

Sorry for my slow response -- I've been catching up after some
vacation time.  Thanks very much for doing all this testing work!
Those results are very good, and it's nice to see such compelling
cases even with FPI enabled.

I'm hoping to commit this in the next few weeks.  There are a few
little todos to tidy up, and I need to do some more review/testing of
the error handling and edge cases.  Any ideas on how to battle test it
are very welcome.  I'm also currently testing how it interacts with
some other patches that are floating around.  More soon.

> #recovery_prefetch = on      # whether to prefetch pages logged with FPW
> #recovery_prefetch_fpw = off # whether to prefetch pages logged with FPW
>
> but clearly that comment is only for recovery_prefetch_fpw, the first
> GUC enables prefetching in general.

Ack, thanks.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)