Re: why there is not VACUUM FULL CONCURRENTLY? - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id CAFj8pRDRnAH9gXBhK2DzXUpgZuNm-BZ3oP6PocHRuBqo1Se2Hg@mail.gmail.com
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: why there is not VACUUM FULL CONCURRENTLY?
List pgsql-hackers
Hi

čt 9. 1. 2025 v 14:35 odesílatel Alvaro Herrera <alvherre@alvh.no-ip.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/

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Adjusting hash join memory limit to handle batch explosion
Next
From: Antonin Houska
Date:
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?