| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Jim Nasby <jnasby(at)upgrade(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Greg Burd <greg(at)burd(dot)me>, Robert Haas <robertmhaas(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: another autovacuum scheduling thread |
| Date: | 2026-03-25 21:24:39 |
| Message-ID: | CALj2ACV0rBhD3aBW-NQs20=ByHkZqhAPzKED=c49y2M4G=3i5g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Wed, Mar 25, 2026 at 2:18 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Wed, Mar 25, 2026 at 02:12:16PM -0700, Bharath Rupireddy wrote:
> > Would it make sense to recompute scores and re-sort the remaining
> > table list after each table is processed in do_autovacuum()'s main
> > loop - say, after a certain amount of time spent vacuuming the large
> > table(s)? This would catch the above scenarios. I see that the scores
> > per table are being calculated in relation_needs_vacanalyze, but they
> > are ignored in the recheck path (table_recheck_autovac ->
> > recheck_relation_needs_vacanalyze -> relation_needs_vacanalyze).
>
> I think this was discussed a bit upthread, and we decided to leave it out
> for now. But things like reprioritization and automatic cost limit
> adjustments seem worth considering for v20.
+1. Thanks for the clarification.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-03-25 21:25:33 | Re: SQL-level pg_datum_image_equal |
| Previous Message | Nathan Bossart | 2026-03-25 21:18:48 | Re: another autovacuum scheduling thread |