Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
От | Alvaro Herrera |
---|---|
Тема | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly |
Дата | |
Msg-id | 20181226181906.z3sxmsbxmkyimnaj@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly |
Список | pgsql-hackers |
On 2018-Dec-26, Robert Haas wrote: > On Mon, Dec 24, 2018 at 6:08 AM Alexey Kondratov > <a.kondratov@postgrespro.ru> wrote: > > I would like to propose a change, which allow CLUSTER, VACUUM FULL and > > REINDEX to modify relation tablespace on the fly. > > ALTER TABLE already has a lot of logic that is oriented towards being > able to do multiple things at the same time. If we added CLUSTER, > VACUUM FULL, and REINDEX to that set, then you could, say, change a > data type, cluster, and change tablespaces all in a single SQL > command. That's a great observation. > That would be cool, but probably a lot of work. :-( But is it? ALTER TABLE is already doing one kind of table rewrite during phase 3, and CLUSTER is just a different kind of table rewrite (which happens to REINDEX), and VACUUM FULL is just a special case of CLUSTER. Maybe what we need is an ALTER TABLE variant that executes CLUSTER's table rewrite during phase 3 instead of its ad-hoc table rewrite. As for REINDEX, I think it's valuable to move tablespace together with the reindexing. You can already do it with the CREATE INDEX CONCURRENTLY recipe we recommend, of course; but REINDEX CONCURRENTLY is not going to provide that, and it seems worth doing. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: