Re: should vacuum's first heap pass be read-only?

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: should vacuum's first heap pass be read-only?
Date: 2022-04-01 04:30:00
Message-ID: CAH2-Wzn8vEBvGAdj0FiQVmZBuwxiXPgkQ9d_WzFwoMseQkwMwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 31, 2022 at 9:08 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> But with the conveyor belt
> we remember the conveyor belt pageno upto which we have done the index
> vacuum and then we only need to do vacuum for the remaining tids which
> will definitely reduce the index vacuuming passes, right?

Right, exactly -- the index or two that really need to be vacuumed a
lot can have relatively small dead_items arrays.

Other indexes (when eventually vacuumed) will need a larger dead_items
array, with everything we need to get rid of from the index in one big
array. Hopefully this won't matter much. Vacuuming these indexes
should be required infrequently (compared to the bloat-prone indexes).

As I said upthread, when we finally have to perform heap vacuuming
(not heap pruning), it'll probably happen because the heap itself
needs heap vacuuming. We could probably get away with *never* vacuum
certain indexes on tables prone to non-HOT updates, without that ever
causing index bloat. But heap line pointer bloat is eventually going
to become a real problem with non-HOT updates, no matter what.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-04-01 04:35:47 Re: head fails to build on SLES 12 (wal_compression=zstd)
Previous Message Kyotaro Horiguchi 2022-04-01 04:21:57 Re: standby recovery fails (tablespace related) (tentative patch and discussion)