Re: WIP: WAL prefetch (another approach)

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: WAL prefetch (another approach)
Date: 2020-10-06 05:04:57
Message-ID: CA+hUKGJyuSTC5sXTv-2FmtjfFPYFU8t8JPnhV4jdMKmuKJ4tHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 24, 2020 at 11:38 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Wed, Sep 9, 2020 at 11:16 AM Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)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 Content-Type Size
v12-0001-Add-pg_atomic_unlocked_add_fetch_XXX.patch text/x-patch 3.4 KB
v12-0002-Improve-information-about-received-WAL.patch text/x-patch 7.8 KB
v12-0003-Provide-XLogReadAhead-to-decode-future-WAL-recor.patch text/x-patch 60.0 KB
v12-0004-Prefetch-referenced-blocks-during-recovery.patch text/x-patch 63.9 KB
v12-0005-WIP-Avoid-extra-buffer-lookup-when-prefetching-W.patch text/x-patch 10.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2020-10-06 05:16:36 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Michael Paquier 2020-10-06 05:02:29 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?