Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-11-25 Thread Peter Geoghegan
On Sat, Aug 6, 2022 at 1:03 PM Peter Geoghegan wrote: > Attached patch teaches autovacuum.c to pass the information down to > lazyvacuum.c, which includes the information in the autovacuum log. > The approach I've taken is very similar to the existing approach with > anti-wraparound autovacuum.

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-09-09 Thread Peter Geoghegan
On Fri, Sep 9, 2022 at 11:11 AM Justin Pryzby wrote: > > It might make sense to *always* show how close we were to hitting each > > of the thresholds, including the ones that we didn't end up hitting > > (we may come pretty close quite often, which seems like it might > > matter). But showing

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-09-09 Thread Justin Pryzby
On Sat, Aug 06, 2022 at 04:09:28PM -0700, Peter Geoghegan wrote: > What are the chances that both thresholds will be crossed at *exactly* > (not approximately) the same time in a real world case, where the > table isn't tiny (tiny relative to the "autovacuum_naptime quantum")? > This is a very

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-08-06 Thread Peter Geoghegan
On Sat, Aug 6, 2022 at 3:51 PM Justin Pryzby wrote: > > Well, autovacuum.c should have (and/or kind of already has) 3 > > different triggering conditions. These are mutually exclusive > > conditions -- technically autovacuum.c always launches an autovacuum > > against a table because exactly 1 of

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-08-06 Thread Justin Pryzby
On Sat, Aug 06, 2022 at 03:41:57PM -0700, Peter Geoghegan wrote: > > > Note that a VACUUM that is an "automatic vacuum for inserted tuples" > > > cannot > > > [...] also be a "regular" autovacuum/VACUUM > > > > Why not ? I think maybe you missed my intent in trimming the "anti-wraparound" part

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-08-06 Thread Peter Geoghegan
On Sat, Aug 6, 2022 at 2:50 PM Justin Pryzby wrote: > This sounded familiar, and it seems like I anticipated that it might be an > issue. Here, I was advocating for the new insert-based GUCs to default to -1, > to have insert-based autovacuum fall back to the thresholds specified by the >

Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-08-06 Thread Justin Pryzby
On Sat, Aug 06, 2022 at 01:03:57PM -0700, Peter Geoghegan wrote: > thresholds. It may be far from obvious which triggering condition > autovacuum.c must have applied to trigger any given autovacuum, since > that information isn't currently passed down to lazyvacuum.c. This > seems like a problem

Making autovacuum logs indicate if insert-based threshold was the triggering condition

2022-08-06 Thread Peter Geoghegan
It's quite possible (and probably very common) for certain tables to have autovacuum scheduling trigger autovacuums based on both the "regular" bloat-orientated thresholds, and the newer insert-based thresholds. It may be far from obvious which triggering condition autovacuum.c must have applied