| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(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:26:48 |
| Message-ID: | CAApHDvpo3YxiaP123vghHL-aLkY2vc-e1scpDSpaTFWz1qVaQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 12 Nov 2025 at 09:13, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Wed, Nov 12, 2025 at 09:03:54AM +1300, David Rowley wrote:
> > /* 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.
Oh, that's a good point. That's a very valid concern. I guess that
could be fixed with a hashtable of vacuumed tables and skipping tables
that exist in there, but the problem with that is that the table might
genuinely need to be vacuumed again. It's a bit tricky to know when a
2nd vacuum is a legit requirement and when it's not. Figuring that out
might me more logic that this code wants to know about.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dagfinn Ilmari Mannsåker | 2025-11-11 20:27:20 | Re: Improve tab completion for various SET/RESET forms |
| Previous Message | Sami Imseih | 2025-11-11 20:25:36 | Re: another autovacuum scheduling thread |