Re: PG17 optimizations to vacuum

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: PG17 optimizations to vacuum
Date: 2024-09-02 19:42:00
Message-ID: CAH2-WzkuMLJxf+s-YzYnsu=7g3HuP9+YAV1vy_yAi2R17cdj-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Sep 2, 2024 at 3:23 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> 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.

That is indeed surprising, given that Pavel's VACUUM VERBOSE output
indicates that the number of heap tuples deleted is identical across
versions. The output also strongly suggests that the same heap pages
are pruned on both versions, since the "index scan needed: " line is
also identical across versions.

Might it be that the extra PRUNE_VACUUM_SCAN records originated in
pages that only contained existing LP_UNUSED items when scanned by
VACUUM?

--
Peter Geoghegan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2024-09-02 19:44:37 Re: Partitioning and unique key
Previous Message Melanie Plageman 2024-09-02 19:23:13 Re: PG17 optimizations to vacuum