Re: [HACKERS] Proposal: Local indexes for partitioned table - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] Proposal: Local indexes for partitioned table
Date
Msg-id 20171220170158.faksdrfp4ncbpmkm@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] Proposal: Local indexes for partitioned table  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Proposal: Local indexes for partitioned table  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Great, thanks for the input.

pg_dump behaves as described upthread -- thanks David and Robert for the
input.  I did this by injecting a fake "INDEX ATTACH" object in
pg_dump's model, which depends on the index-on-parent-table; which in
turn depends on the index-on-partition.  Because of the dependencies,
the attach is dumped last, and the index-on-parent is dumped after all
the indexes-on-partitions have been dumped.  I needed to apply a little
bit of surgery so that each table object would contain links to its
indexes, which previously wasn't there.  A followup step to obtaining
index info creates the INDEX ATTACH objects.

In the backend code: There is now a difference in initial setting of
indisvalid and indisready when creating an index.  Previously we always
set them the same (!concurrent) but now indisready depends only on
"concurrent" while indisvalid additionally depends on whether a a
non-inherited index on a partitioned table is being built.  Failing to
set indisready to true initially was causing the index to be invisible
to pg_dump.

There is no ALTER INDEX / DETACH, as discussed.  Also, trying to attach
an index for a partition that already contains an attached index raises
an error -- which means that in order to determine whether attaching an
index as partition makes the parent index valid, is a simple matter of
counting tuples.

All these behaviors are immortalized in the regression tests.

I added tab-complete support too (thanks Jesper for the reminder).  It
is probably not exhaustive, but should be good enough.

I have two patches to rebase on top of this, which I hope to post later
today:

1) let these indexes be unique (i.e. allow unique and PK constraints)
2) allow foreign keys on partitioned tables

I have a further patch to allow FOR EACH ROW triggers on partitioned
tables, but I think it's largely unrelated to this (and, as I was
surprised to discover, it's also unrelated to the FKs one).

Thanks

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

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: AS OF queries
Next
From: Tom Lane
Date:
Subject: Re: Letting plpgsql in on the fun with the new expression eval stuff