MIME-Version: 1.0
References: <3bda0d10-0d60-42b7-9600-abe23d54bb16@postgrespro.ru>
 <CAH2-Wz=pCtsB3v42RB5dLnzEn3tQLUJ8fJMn+si-9A8s6v=B1A@mail.gmail.com>
 <CAAKRu_aBthDxatwzR-wQ8bWfYehuxYgAO0g6AMPFyVgdOxfS4g@mail.gmail.com>
 <CAH2-Wznqbnc8en8+B26obp-pmTKXi_HS_h_yRt4HVtqLOCKxLQ@mail.gmail.com>
 <CAAKRu_YF9UeFnfsgDiFybAss2YQtmEHU+xjngqwmwwyQjCDvxQ@mail.gmail.com> <7bc8da54-fe4f-4ff2-aa4e-b54fc91df586@postgrespro.ru>
In-Reply-To: <7bc8da54-fe4f-4ff2-aa4e-b54fc91df586@postgrespro.ru>
From: Peter Geoghegan <pg@bowt.ie>
Date: Mon, 2 Sep 2024 16:58:49 -0400
Message-ID: <CAH2-Wz=dYGM1=ONVYd2jUdZP8bQy0t8G9o6PpoRWGbvbN-uPBA@mail.gmail.com>
Subject: Re: PG17 optimizations to vacuum
To: Pavel Luzanov <p.luzanov@postgrespro.ru>
Cc: Melanie Plageman <melanieplageman@gmail.com>, 
	"pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAH2-Wz%3DdYGM1%3DONVYd2jUdZP8bQy0t8G9o6PpoRWGbvbN-uPBA%40mail.gmail.com>
Precedence: bulk

On Mon, Sep 2, 2024 at 4:35=E2=80=AFPM Pavel Luzanov <p.luzanov@postgrespro=
.ru> wrote:
> If it helps, without creating index on id column, the numbers will be
> much closer:

Yes, avoiding all index vacuuming seems useful. It makes the test case
cleaner, since we don't have to think about the variability from the
TIDStore work (and from index vacuuming more generally).

> master:
> WAL usage: 78502 records, 22090 full page images, 196215494 bytes
>
> v15:
> WAL usage: 77437 records, 30872 full page images, 152080268 bytes

To be clear, I wouldn't be all that surprised if some issue with
alignment padding and/or the new WAL format made master write more
bytes of WAL total than on earlier versions. Small inefficiencies like
that were always a possibility. That's not the problem that I'm
principally concerned about right now.

I'm most concerned about the simple fact that we're writing more
individual WAL records than on previous versions, despite the fact
that VACUUM does exactly the same amount of useful pruning and
freezing work across versions. How could a patch that merged together
the previous PRUNE and VACUUM WAL record types into a single record
type actually cause an increase in the number of WAL records written?
I'd have thought that that was simply impossible.

--=20
Peter Geoghegan