Re: why there is not VACUUM FULL CONCURRENTLY?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
Date: 2025-01-09 17:08:39
Message-ID: CAFj8pRDRnAH9gXBhK2DzXUpgZuNm-BZ3oP6PocHRuBqo1Se2Hg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

čt 9. 1. 2025 v 14:35 odesílatel Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
napsal:

> On 2024-Dec-11, Antonin Houska wrote:
>
> > Oh, it was too messy. I think I was thinking of too many things at once
> (such
> > as locking the old heap, the new heap and the new heap's TOAST). Also,
> one
> > thing that might have contributed to the confusion is that
> make_new_heap() has
> > the 'lockmode' argument, which receives various values from various
> > callers. However, both the new heap and its TOAST relation are eventually
> > created by heap_create_with_catalog(), and this function always leaves
> the new
> > relation locked in AccessExclusiveMode. Maybe this needs some
> refactoring.
> >
> > Therefore I reverted the changes arount make_new_heap() and simply pass
> NoLock
> > for lockmode in cluster.c
>
> Cool, thanks, I have pushed this. I made some additional minor changes,
> nothing earth-shattering.
>
> Meanwhile the patch 0004 has some seemingly trivial conflicts. If you
> want to rebase, I'd appreciate that. In the meantime I'll give a look
> at the next two other API changes.
>
> I'm not happy with the idea of having this new command be VACUUM (FULL
> CONCURRENTLY). It's a bit of an absurd name if you ask me. Heck, even
> VACUUM (FULL) seems a bit absurd nowadays.
>

Although it can sound absurd - it makes perfect sense for me - both "FULL"
and "CONCURRENTLY" are years used terms.

Maybe we can introduce a synonym like COMPACT for FULL.

I don't see a strong benefit for introducing a new command (with almost all
identical functionality) just because the words sound strange. But I
understand this.
There is inconsistency between behaviour of VACUUM COMMAND - lazy VACUUM is
by default CONCURRENTLY, but FULL VACUUM NOT, so I understand
to request to introduce a new command. But is it really necessary?

Introducing synonyms for (FULL) COMPACT or SQUEEZE can be enough, and can
work well. It is better than the introduction synonym for VACUUM command.

Regards

Pavel

> Maybe we should have a new toplevel command. Some ideas that have been
> thrown around:
>
> - RETABLE (it's like REINDEX, but for tables)
> - ALTER TABLE <tab> SQUEEZE
> - SQUEEZE <table>
> - VACUUM (SQUEEZE)
> - VACUUM (COMPACT)
> - MAINTAIN <tab> COMPACT
> - MAINTAIN <tab> SQUEEZE
>
> --
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2025-01-09 17:26:02 Re: why there is not VACUUM FULL CONCURRENTLY?
Previous Message Tomas Vondra 2025-01-09 17:01:55 Re: Adjusting hash join memory limit to handle batch explosion