From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, "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-04-05 20:32:00 |
Message-ID: | qqguhicg3gvzs6z6enomx4mpcowvlknxuwtelbhmivmkdj622s@bgo25mtkeoxe |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-04-04 14:34:53 -0700, Masahiko Sawada wrote:
> On Fri, Apr 4, 2025 at 11:05 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> >
> > On Tue, Apr 1, 2025 at 5:30 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > >
> > > I've attached the new version patch. There are no major changes; I
> > > fixed some typos, improved the comment, and removed duplicated codes.
> > > Also, I've updated the commit messages.
> >
> > I haven't looked closely at this version but I did notice that you do
> > not document that parallel vacuum disables eager scanning. Imagine you
> > are a user who has set the eager freeze related table storage option
> > (vacuum_max_eager_freeze_failure_rate) and you schedule a regular
> > parallel vacuum. Now that table storage option does nothing.
>
> Good point. That restriction should be mentioned in the documentation.
> I'll update the patch.
I don't think we commonly accept that a new feature B regresses a pre-existing
feature A, particularly not if feature B is enabled by default. Why would that
be OK here?
The justification in the code:
+ * One might think that it would make sense to use the eager scanning even
+ * during parallel lazy vacuum, but parallel vacuum is available only in
+ * VACUUM command and would not be something that happens frequently,
+ * which seems not fit to the purpose of the eager scanning. Also, it
+ * would require making the code complex. So it would make sense to
+ * disable it for now.
feels not at all convincing to me. There e.g. are lots of places that run
nightly vacuums. I don't think it's ok to just disable eager scanning in such
a case, as it would mean that the "freeze cliff" would end up being *higher*
because of the nightly vacuums than if just plain autovacuum would have been
used.
I think it was already a mistake to allow the existing vacuum parallelism to
be introduced without integrating it with autovacuum. I don't think we should
go further down that road.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-05 20:37:08 | Re: CREATE OR REPLACE MATERIALIZED VIEW |
Previous Message | Heikki Linnakangas | 2025-04-05 20:17:50 | Re: In-placre persistance change of a relation |