Re: partitioned indexes and tablespaces - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: partitioned indexes and tablespaces
Date
Msg-id ceac1fe6-1883-39ef-68ff-167fb2ba5a60@2ndQuadrant.com
Whole thread Raw
In response to Re: partitioned indexes and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: partitioned indexes and tablespaces
List 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 by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: pgbench -M option can be specified more than once
Next
From: "Daniel Verite"
Date:
Subject: Re: COPY FROM WHEN condition