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

From Thomas Munro
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id CA+hUKGJyuSTC5sXTv-2FmtjfFPYFU8t8JPnhV4jdMKmuKJ4tHw@mail.gmail.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: WIP: WAL prefetch (another approach)
List pgsql-hackers
On Thu, Sep 24, 2020 at 11:38 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Wed, Sep 9, 2020 at 11:16 AM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
> > OK, thanks for looking into this. I guess I'll wait for an updated patch
> > before testing this further. The storage has limited capacity so I'd
> > have to either reduce the amount of data/WAL or juggle with the WAL
> > segments somehow. Doesn't seem worth it.
>
> Here's a new WIP version that works for archive-based recovery in my tests.

Rebased over recent merge conflicts in xlog.c.  I also removed a stray
debugging message.

One problem the current patch has is that if you use something like
pg_standby, that is, a restore command that waits for more data, then
it'll block waiting for WAL when it's trying to prefetch, which means
that replay is delayed.  I'm not sure what to think about that yet.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions