| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel heap vacuum |
| Date: | 2025-09-18 14:58:32 |
| Message-ID: | CA+TgmobuWNgPmKVpi51LApR=sVn==TmMmyopG59_tzDQHasOig@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 17, 2025 at 7:22 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I continue to find this argument extremely unconvincing. It's very common for
> autovacuum to be continuously be busy with the one large table that has a
> bunch of indexes. Vacuuming that one table is what prevents the freeze horizon
> to move forward / prevents getting out of anti-wraparound territory in time.
The problem is that we're not smart enough to know whether this is the
case or not. It's also fairly common for tables to get starved because
all of the autovacuum workers are busy. Until we get a real scheduling
system for autovacuum, I don't see this area improving very much.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-09-18 15:13:11 | Re: someone else to do the list of acknowledgments |
| Previous Message | Bruce Momjian | 2025-09-18 14:56:35 | Re: REPACK and naming |