Re: partitioned indexes and tablespaces
От | Andrew Dunstan |
---|---|
Тема | Re: partitioned indexes and tablespaces |
Дата | |
Msg-id | ceac1fe6-1883-39ef-68ff-167fb2ba5a60@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: partitioned indexes and tablespaces (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: partitioned indexes and tablespaces
|
Список | pgsql-hackers |
On 11/02/2018 07:12 PM, Alvaro Herrera wrote: > On 2018-Nov-03, Michael Paquier wrote: > >> On Fri, Nov 02, 2018 at 03:53:51PM -0300, Alvaro Herrera wrote: >>> In this thread I'm not proposing to change the behavior for tables, only >>> for indexes. If people want to change behavior for tables (and I agree >>> with doing so), they can start their own threads. >> Changing this behavior on back-branches is not a good idea I think >> because that changes the representation of the pg_class entries in the >> catalogs by adding the reltablespace reference for a partitioned index >> which does not exist now. We are long past the time of doing such >> changes on v11, but that can perfectly be done for v12. > With all due respect, this argument makes no sense. All partitioned > indexes that exist today have a null reltablespace (all pg_class rows > already have a reltablespace column; I'm not changing that). If users > want to keep the current behavior (i.e. that indexes on future > partitions are created in the default tablespace), all they have to do > is not send any ALTER INDEX changing the index's tablespace. > > You're saying that people currently running Postgres 11 that are > doing "CREATE INDEX ... TABLESPACE foo" will be surprised because the > index ends up in tablespace foo for partitions they create afterwards. > > Additionally, you're saying that all people currently doing > ALTER INDEX ... SET TABLESPACE foo > expect that > 1. the parent partitioned index silently does not change at all > 2. the indexes on future partitions end up in the default tablespace. > > I cannot see how that's for real. > > Furthermore, I think delaying this change to pg12 serves nobody, because > it just means that there will be a behavior difference for no reason. > +1. This is unquestionably a POLA violation that should be fixed, IMNSHO. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: