Re: Teaching users how they can get the most out of HOT in Postgres 14
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-13T00:37:14Z
Lists: pgsql-hackers
Hi, On 2021-04-12 16:53:47 -0700, Peter Geoghegan wrote: > On Mon, Apr 12, 2021 at 4:52 PM Michael Paquier <michael@paquier.xyz> wrote: > > While going through this commit a couple of days ago, I really got to > > wonder why you are controlling this stuff with a hardcoded value and I > > found that scary, while what you should be using are two GUCs with the > > reloptions that come with the feature (?): > > - A threshold, as an integer, to define a number of pages. > > - A scale factor to define a percentage of pages. > > Why? Well, one argument is that you made a fairly significant behavioural change, with hard-coded logic for when the optimization kicks in. It's not at all clear that your constants are the right ones for every workload. We'll likely on get to know whether they're right in > 1 year - not having a real out at that point imo is somewhat scary. That said, adding more and more reloptions has a significant cost, so I don't think it's clear cut that it's the right decision to add one. Perhaps vacuum_cleanup_index_scale_factor should just be reused for BYPASS_THRESHOLD_PAGES? Greetings, Andres Freund
Commits
-
Support disabling index bypassing by VACUUM.
- 3499df0dee8c 14.0 landed
-
Teach VACUUM to bypass unnecessary index vacuuming.
- 5100010ee4d5 14.0 cited