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
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) |