Re: CREATE DATABASE ... STRATEGY WAL_LOG issues

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: CREATE DATABASE ... STRATEGY WAL_LOG issues
Date: 2023-03-21 15:33:59
Message-ID: CA+Tgmob17QX145hwG+xy2sbdwNJx457YGOoo9BEEruJBg10yDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 21, 2023 at 3:01 AM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-03-21 15:35:16 PostgreSQL 16 Release Management Team & Feature Freeze
Previous Message Pavel Stehule 2023-03-21 15:33:18 Re: proposal: possibility to read dumped table's name from file