|From:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|To:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Maksim Milyutin <milyutinma(at)gmail(dot)com>|
|Subject:||Re: [HACKERS] Proposal: Local indexes for partitioned table|
|Views:||Raw Message | Whole Thread | Download mbox|
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
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
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
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).
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Tom Lane||2017-12-20 17:12:48||Re: Letting plpgsql in on the fun with the new expression eval stuff|
|Previous Message||Magnus Hagander||2017-12-20 16:26:29||Re: AS OF queries|