Re: why there is not VACUUM FULL CONCURRENTLY?
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Antonin Houska <ah@cybertec.at>, Junwang Zhao <zhjwpku@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-09T17:08:39Z
Lists: 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/ >
Commits
-
Add CONCURRENTLY option to REPACK
- 28d534e2ae0a 19 (unreleased) landed
-
Introduce the REPACK command
- ac58465e0618 19 (unreleased) landed
-
Adjust signature of cluster_rel() and its subroutines
- cc811f92bac5 18.0 landed
-
Simplify signature of RewriteTable
- ebd8fc7e47fd 18.0 cited