Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Alexey Kondratov <a.kondratov@postgrespro.ru>
From: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-24T11:08:43Z
Lists: pgsql-hackers
Attachments
Hi Hackers,
I would like to propose a change, which allow CLUSTER, VACUUM FULL and
REINDEX to modify relation tablespace on the fly. Actually, all these
commands rebuild relation filenodes from the scratch, thus it seems
natural to allow specifying them a new location. It may be helpful, when
a server went out of disk, so you can attach new partition and perform
e.g. VACUUM FULL, which will free some space and move data to a new
location at the same time. Otherwise, you cannot complete VACUUM FULL
until you have up to x2 relation disk space on a single partition.
Please, find attached a patch, which extend CLUSTER, VACUUM FULL and
REINDEX with additional options:
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE } name [ SET TABLESPACE
new_tablespace ]
CLUSTER [VERBOSE] table_name [ USING index_name ] [ SET TABLESPACE
new_tablespace ]
CLUSTER [VERBOSE] [ SET TABLESPACE new_tablespace ]
VACUUM ( FULL [, ...] ) [ SET TABLESPACE new_tablespace ] [
table_and_columns [, ...] ]
VACUUM FULL [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ SET TABLESPACE
new_tablespace ] [ table_and_columns [, ...] ]
Thereby I have a few questions:
1) What do you think about this concept in general?
2) Is SET TABLESPACE an appropriate syntax for this functionality? I
thought also about a plain TABLESPACE keyword, but it seems to be
misleading, and WITH (options) clause like in CREATE SUBSCRIPTION ...
WITH (options). So I preferred SET TABLESPACE, since the same syntax is
used currently in ALTER to change tablespace, but maybe someone will
have a better idea.
3) I was not able to update the lexer for VACUUM FULL to use SET
TABLESPACE after table_and_columns and completely get rid of
shift/reduce conflicts. I guess it happens, since table_and_columns is
optional and may be of variable length, but have no idea how to deal
with it. Any thoughts?
Regards
--
Alexey Kondratov
Postgres Professionalhttps://www.postgrespro.com
Russian Postgres Company
Commits
-
Add TABLESPACE option to REINDEX
- c5b286047cd6 14.0 landed
-
Refactor code in tablecmds.c to check and process tablespace moves
- 4c9c359d38ff 14.0 landed
-
Refactor option handling of CLUSTER, REINDEX and VACUUM
- a3dc926009be 14.0 landed
-
pg_dump: Don't use enums for defining bit mask values
- d2a2808eb444 14.0 landed
-
Refactor CLUSTER and REINDEX grammar to use DefElem for option lists
- b5913f612079 14.0 landed
-
Refactor parsing rules for option lists of EXPLAIN, VACUUM and ANALYZE
- 873ea9ee692e 14.0 landed
-
Improve tab completion of REINDEX in psql
- 1f75b454134c 14.0 landed
-
Fix possible crash during FATAL exit from reindexing.
- d12bdba77b0f 13.0 cited