Re: partitioned indexes and tablespaces

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: partitioned indexes and tablespaces
Date: 2018-11-02 23:12:15
Message-ID: 20181102231215.26fwfg66vdnlckq2@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas 'ads' Scherbaum 2018-11-02 23:14:12 Re: INSTALL file
Previous Message Michael Paquier 2018-11-02 23:02:36 Re: pg_promote not marked as parallel-restricted in pg_proc.dat