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 Z7ZUWje-e1e_fKeu@nathan
Whole thread Raw
In response to Re: Trigger more frequent autovacuums of heavy insert tables  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Trigger more frequent autovacuums of heavy insert tables
List pgsql-hackers
On Wed, Feb 19, 2025 at 04:36:05PM -0500, Melanie Plageman wrote:
> This makes me think I should also not cap relallfrozen when using it
> in relation_needs_vacanalyze(). There I cap it to relallvisible and
> relallvisible is capped to relpages. One of the ideas behind letting
> people modify these stats in pg_class is that they can change a single
> field to see what the effect on their system is, right?

Right.  Capping these values to reflect reality seems like it could make
that more difficult.

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

It's probably not strictly required, but my naive expectation would be that
we'd handle relallfrozen just like relallvisible, which appears to be
dumped in the latest stats import/export patch.  Is there any reason we
shouldn't do the same for relallfrozen?

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18815: Logical replication worker Segmentation fault
Next
From: Andrew Dunstan
Date:
Subject: Re: IPC::Run::time[r|out] vs our TAP tests