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

From Michael Paquier
Subject Re: partitioned indexes and tablespaces
Date
Msg-id 20181102225937.GA1899@paquier.xyz
Whole thread Raw
In response to Re: partitioned indexes and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: partitioned indexes and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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.

Making the tablespace inherited from the parent if the parent has no
information on disk is sensible in my opinion, so please let's consider
that as a feature but not a bug, and also let's do the change for both
partitioned tables *and* partitioned indexes for consistency.  The
current behavior does not prevent the features to work.

So what I would suggest is to fix the commands which are failing by not
ignoring partitioned indexes for v11, then raise a new thread which
implements the new tablespace behavior for all partitioned objects.  Per
my recent lookups at partition-related features, making a maximum
consistency between how partitioned tables and partitioned indexes
behave is actually a good approach.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Next
From: Michael Paquier
Date:
Subject: Re: pg_promote not marked as parallel-restricted in pg_proc.dat