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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: pgbench -M option can be specified more than once
Следующее
От: "Daniel Verite"
Дата:
Сообщение: Re: COPY FROM WHEN condition