| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowley(at)gmail(dot)com> |
| Subject: | Re: Trigger more frequent autovacuums of heavy insert tables |
| Date: | 2025-02-19 21:59:54 |
| Message-ID: | Z7ZUWje-e1e_fKeu@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2025-02-19 22:08:03 | Re: IPC::Run::time[r|out] vs our TAP tests |
| Previous Message | Tom Lane | 2025-02-19 21:55:52 | Re: BUG #18815: Logical replication worker Segmentation fault |