| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Robert Treat <rob(at)xzilla(dot)net>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, satyanarlapuram(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add pg_stat_autovacuum_priority |
| Date: | 2026-03-31 16:41:08 |
| Message-ID: | CAA5RZ0tOqsAUxqDBO0zWr_MA+w5mDcZkiQLoZPyBhGwHWBVQgA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> >> I also see that we're not forcing the computation of the (M)XID
> >> scores. Is that intentional?
> >
> > hmm, the force_score does not need to be in the force_vacuum path
> > because the score is calculated there naturally when the table is in
> > need of force_vacuum. The force_score is there to ensure that
> > we are not existing early in the autovacuum disabled case.
>
> So, unless the table is beyond a freeze-max-age parameter, the (M)XID
> scores will always be 0.0?
You're right after thinking about this again. There is no reason why we
should treat the force_vacuum case differently. The score should still
be included so someone monitoring can see the xid|mxid_age climbing
well before it becomes an issue.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-03-31 16:45:08 | Re: Introduce XID age based replication slot invalidation |
| Previous Message | Nathan Bossart | 2026-03-31 16:30:54 | Re: Speed up COPY TO text/CSV parsing using SIMD |