public inbox for [email protected]
help / color / mirror / Atom feedFrom: Melanie Plageman <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: Pavel Luzanov <[email protected]>
Cc: pgsql-generallists.postgresql.org <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Subject: Re: PG17 optimizations to vacuum
Date: Mon, 2 Sep 2024 15:23:13 -0400
Message-ID: <CAAKRu_YF9UeFnfsgDiFybAss2YQtmEHU+xjngqwmwwyQjCDvxQ@mail.gmail.com> (raw)
In-Reply-To: <CAH2-Wznqbnc8en8+B26obp-pmTKXi_HS_h_yRt4HVtqLOCKxLQ@mail.gmail.com>
References: <[email protected]>
<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>
On Mon, Sep 2, 2024 at 1:47 PM Peter Geoghegan <[email protected]> wrote:
>
> On Mon, Sep 2, 2024 at 1:29 PM Melanie Plageman
> <[email protected]> wrote:
> > I'll investigate more tomorrow, but based on my initial investigation,
> > there appears to be some interaction related to how much of the
> > relation is in shared buffers after creating the table and updating
> > it. If you set shared_buffers sufficiently high and prewarm the table
> > after the update, master has fewer WAL records reported by vacuum
> > verbose.
>
> Fewer of what specific kind of WAL record?
I would have expected to see no freeze records (since they no longer
exist) and the same number of prune records. However, the overall
number of records that I get for 16 and master is pretty similar. For
some reason I stopped being able to reproduce Pavel's case. I'll work
more on it tomorrow.
This is roughly what I get for records by vacuum. Note that I prefixed
VACUUM with BTREE on master to indicate those records are from index
vacuuming. By default the headesc routine for records emitted by index
vacuuming prints just VACUUM -- perhaps it would be better to prefix
it.
Note that these add up to almost the same thing. I don't know yet why
the number PRUNE_VACUUM_SCAN is different than PRUNE on 16.
PRUNE_VACUUM_SCAN and PRUNE + FREEZE_PAGE on 16 are similar. So, there
must be pages that don't have items being pruned which are being
frozen. I'll need to investigate further.
master
--
PRUNE_ON_ACCESS | 6
PRUNE_VACUUM_SCAN | 30974
PRUNE_VACUUM_CLEANUP | 14162
BTREE_VACUUM | 19127
16
--
PRUNE | 15504
FREEZE_PAGE | 13257
VACUUM | 34527
- Melanie
view thread (7+ 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], [email protected], [email protected], [email protected]
Subject: Re: PG17 optimizations to vacuum
In-Reply-To: <CAAKRu_YF9UeFnfsgDiFybAss2YQtmEHU+xjngqwmwwyQjCDvxQ@mail.gmail.com>
* 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