| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: another autovacuum scheduling thread |
| Date: | 2025-11-11 20:13:44 |
| Message-ID: | aROY-MUVO_mYTl2f@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 12, 2025 at 09:03:54AM +1300, David Rowley wrote:
> I'm still trying to work out what Sami sees in the results that he
> doesn't think is good. I resuggested he try coding up the periodic
> refresh-the-list code to see if it makes the thing he sees better. I
> was hoping that we could get away with not doing that for stage 1 of
> this. My concern there is that these change-the-way-autovacuum-works
> patches seems to blow up quickly as everyone chips in with autovacuum
> problems they want fixed and expect the patch to do it all.
+1
> That said, the periodic refresh probably isn't too hard. I suspected
> it was something like:
>
> /* when enough time has passed, refresh the list to ensure the
> scores aren't too out-of-date */
> if (time is > lastcheck + autovacuum_naptime * <something>)
> {
> list_free_deep(tables_to_process);
> goto the_top;
> }
> } // end of foreach(cell, tables_to_process)
My concern is that this might add already-processed tables back to the
list, so a worker might never be able to clear it. Maybe that's not a real
problem in practice for some reason, but it does feel like a step too far
for stage 1, as you said above.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-11-11 20:16:37 | Re: another autovacuum scheduling thread |
| Previous Message | David Rowley | 2025-11-11 20:03:54 | Re: another autovacuum scheduling thread |