Re: New IndexAM API controlling index vacuum strategies
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-03T03:39:57Z
Lists: pgsql-hackers
On Tue, Mar 2, 2021 at 6:44 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > A scale type parameter seems good to me but I wonder if how users can > tune that parameter. We already have tuple-based parameters such as > autovacuum_vacuum_scale_factor/threshold and I think that users > basically don't pay attention to that table updates result in how many > blocks. Fair. The scale thing was just a random suggestion, nothing to take too seriously. > The third idea is a VACUUM command option like DISABLE_PAGE_SKIPPING > to disable such skipping behavior. I imagine that the > user-controllable-option to enforce both heap vacuum and index vacuum > would be required also in the future when we have the vacuum strategy > feature (i.g., incremental vacuum). Yeah, I'm worried about conflicting requirements here -- this patch and the next patch (that pushes the same ideas further) might have different requirements. I think that this patch will mostly be useful in cases where there are very few LP_DEAD-containing heap pages, but consistently more than zero. So it's probably not easy to tune. What we might want is an on/off switch. But why? DISABLE_PAGE_SKIPPING was added because the freeze map work in 9.6 was considered high risk at the time, and we needed to have a tool to manage that risk. But this patch doesn't seem nearly as tricky. No? > > Lots of stuff in this area is kind of weird already. Sometimes this is > > directly exposed to users, even. This came up recently, when I was > > working on VACUUM VERBOSE stuff. > That's true. I didn't know that. It occurs to me that "tups_vacuumed vs. total LP_DEAD Items in heap after VACUUM finishes" is similar to "pages_newly_deleted vs. pages_deleted" for indexes. An easy mistake to make! > > https://www.postgresql.org/message-id/flat/20130108024957.GA4751%40tornado.leadboat.com > > > > Of course, this effort to eliminate the "tupgone = > > true"/XLOG_HEAP2_CLEANUP_INFO special case didn't go anywhere at the > > time. > > I'll look at that thread. I'm not sure if it's super valuable to look at the thread. But it is reassuring to see that Noah shared the intuition that the "tupgone = true" case was kind of bad, even back in 2013. It's one part of my "mental map" of VACUUM. -- Peter Geoghegan
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't truncate heap when VACUUM's failsafe is in effect.
- 60f1f09ff443 14.0 landed
-
Teach VACUUM to bypass unnecessary index vacuuming.
- 5100010ee4d5 14.0 landed
-
Add wraparound failsafe to VACUUM.
- 1e55e7d1755c 14.0 landed
-
Truncate line pointer array during VACUUM.
- 3c3b8a4b2689 14.0 landed
-
Remove tupgone special case from vacuumlazy.c.
- 8523492d4e34 14.0 landed
-
Refactor lazy_scan_heap() loop.
- 7ab96cf6b312 14.0 landed
-
Propagate parallel VACUUM's buffer access strategy.
- 49f49defe7c0 14.0 cited
-
Simplify state managed by VACUUM.
- b4af70cb2103 14.0 landed
-
Notice that heap page has dead items during VACUUM.
- 0ea71c93a06d 14.0 landed
-
Adjust lazy_scan_heap() accounting comments.
- 7cde6b13a9b6 14.0 cited
-
Use full 64-bit XID for checking if a deleted GiST page is old enough.
- 6655a7299d83 13.0 cited
-
Fix some problems with VACUUM (INDEX_CLEANUP FALSE).
- dd6959798885 12.0 cited