public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: optimize file transfer in pg_upgrade
Date: Fri, 28 Feb 2025 14:51:27 -0600
Message-ID: <Z8Ihz3by-r5t1m30@nathan> (raw)
In-Reply-To: <CA+TgmobD+yMc_jkmk=Vr0UWm9y8AyRFdH+CLZaCukFUoXpCG2A@mail.gmail.com>
References: <Zyvop-LxLXBLrZil@nathan>
<CA+Tgmobi1aiWhtfJXL2PZsEsXOHRivRykMxE1kcTDb4EwEfj-w@mail.gmail.com>
<CA+TgmoY6VZT=HzuJ_zfrt=2Vi7EHfVfwMd3AOuEfw-f7aeR-AQ@mail.gmail.com>
<Z8IWHJ7OdMnQ45ur@nathan>
<CA+TgmobD+yMc_jkmk=Vr0UWm9y8AyRFdH+CLZaCukFUoXpCG2A@mail.gmail.com>
On Fri, Feb 28, 2025 at 03:37:49PM -0500, Robert Haas wrote:
> On Fri, Feb 28, 2025 at 3:01 PM Nathan Bossart <[email protected]> wrote:
>> That's exactly where I landed (see v3-0002). I haven't measured whether
>> transferring relfilenodes or dumping the sequence data is faster for the
>> existing modes, but for now I've left those alone, i.e., they still dump
>> sequence data. The new "swap" mode just uses the old cluster's sequence
>> files, and I've disallowed using swap mode for upgrades from <v10 to avoid
>> the sequence tuple format change (along with other incompatible changes).
>
> Ah. Perhaps I should have read the thread more carefully before
> commenting. Sounds good, at any rate.
On the contrary, I'm glad you independently came to the same conclusion.
>> I'll admit I'm a bit concerned that this will cause problems if and when
>> someone wants to change the sequence tuple format again. But that hasn't
>> happened for a while, AFAIK nobody's planning to change it, and even if it
>> does happen, we just need to have my proposed new mode transfer the
>> sequence files like it transfers the catalog files. That will make this
>> mode slower, especially if you have a ton of sequences, but maybe it'll
>> still be a win in most cases. Of course, we probably will need to have
>> pg_upgrade handle other kinds of format changes, too, but IMHO it's still
>> worth trying to speed up pg_upgrade despite the potential future
>> complexities.
>
> I think it's fine. If somebody comes along and says "hey, when v23
> came out Nathan's feature only sped up pg_upgrade by 2x instead of 3x
> like it did for v22, so Nathan is a bad person," I think we can fairly
> reply "thanks for sharing your opinion, feel free not to use the
> feature and run at 1x speed". There's no rule saying that every
> optimization must always produce the maximum possible benefit in every
> scenario. We're just concerned about regressions, and "only delivers
> some of the speedup if the sequence format has changed on disk" is not
> a regression.
Cool. I appreciate the design feedback.
--
nathan
view thread (34+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: optimize file transfer in pg_upgrade
In-Reply-To: <Z8Ihz3by-r5t1m30@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox