Re: CREATE DATABASE ... STRATEGY WAL_LOG issues - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CREATE DATABASE ... STRATEGY WAL_LOG issues
Date
Msg-id CA+Tgmob17QX145hwG+xy2sbdwNJx457YGOoo9BEEruJBg10yDg@mail.gmail.com
Whole thread Raw
In response to CREATE DATABASE ... STRATEGY WAL_LOG issues  (Andres Freund <andres@anarazel.de>)
Responses Re: CREATE DATABASE ... STRATEGY WAL_LOG issues  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Mar 21, 2023 at 3:01 AM Andres Freund <andres@anarazel.de> wrote:
> While hacking on my relation extension patch I found two issues with WAL_LOG:
>
> 1) RelationCopyStorageUsingBuffer() doesn't free the used strategies. This
>    means we'll use #relations * ~10k memory

Woops.

> 2) RelationCopyStorageUsingBuffer() gets the buffer for the target relation
>    with RBM_NORMAL, therefore requiring a read of a block guaranteed to be
>    zero

Woops.

> Easy enough to fix and shows clear improvement. One thing I wonder is if it's
> worth moving the strategies up one level? Probaly not, but ...

Hmm, so share a strategy across all relation forks? You could even
push it up a level beyond that and share it across all relations being
copied. That feels like it would be slightly more rational behavior,
but I'm not smart enough to guess whether anyone would actually be
happier (or less happy) after such a change than they are now.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file
Next
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 16 Release Management Team & Feature Freeze