Re: Trigger more frequent autovacuums of heavy insert tables - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Trigger more frequent autovacuums of heavy insert tables
Date
Msg-id Z7Nfv91GrQtLXP4q@nathan
Whole thread Raw
In response to Re: Trigger more frequent autovacuums of heavy insert tables  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Trigger more frequent autovacuums of heavy insert tables
List pgsql-hackers
On Fri, Feb 07, 2025 at 03:05:09PM -0600, Nathan Bossart wrote:
> Okay, I'll actually look at the patches next...

Ugh, it's already been 10 days since I said that.  A couple of thoughts on
0001:

I'm not sure I understand the reason for capping relallfrozen to
relallvisible.  From upthread, I gather this is mostly to deal with manual
statistics manipulation, but my first reaction is that we should just let
those values be bogus.  Is there something that fundamentally requires
relallfrozen to be <= relallvisible?  These are only estimates, so I don't
think it would be that surprising for them to defy this expectation.

Should we allow manipulating relallfrozen like we do relallvisible?  My
assumption is that would even be required for the ongoing statistics
import/export work.

Upthread, you mentioned that you weren't seeing relallfrozen in
pg_class_d.h.  I checked on my machine and see it there as expected.  Are
you still missing it?

-- 
nathan



pgsql-hackers by date:

Previous
From: Mark Wong
Date:
Subject: Re: New buildfarm animals with FIPS mode enabled
Next
From: vignesh C
Date:
Subject: Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.