Horton

Re: [HACKERS] Proposal: Local indexes for partitioned table

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

View thread View on postgr.es
From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Simon Riggs <simon@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Maksim Milyutin <milyutinma@gmail.com>
Date: 2017-12-06T01:11:22Z
Lists: pgsql-hackers 
On Wed, Dec 6, 2017 at 9:42 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 6 December 2017 at 11:35, Robert Haas <robertmhaas@gmail.com> wrote:
>> What are we giving up by explicitly attaching
>> the correct index?
>
> The part I don't like about the ATTACH and DETACH of partitioned index
> is that it seems to be trying to just follow the syntax we use to
> remove a partition from a partitioned table, however, there's a huge
> difference between the two, as DETACHing a partition from a
> partitioned table leaves the partitioned table in a valid state, it
> simply just no longer contains the detached partition. With the
> partitioned index, we leave the index in an invalid state after a
> DETACH. It can only be made valid again once another leaf index has
> been ATTACHED again and that we've verified that all other indexes on
> every leaf partition is also there and are valid. If we're going to
> use these indexes to answer queries, then it seems like we should try
> to keep them valid so that queries can actually use them for
> something.
>

+1 for all that. Exactly my thoughts.


-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Commits

  1. Local partitioned indexes

  2. Fix StoreCatalogInheritance1 to use 32bit inhseqno

  3. Get rid of copy_partition_key

  4. Simplify index_[constraint_]create API