Re: [HACKERS] Proposal: Local indexes for partitioned table
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Proposal: Local indexes for partitioned table |
Дата | |
Msg-id | 20171220170158.faksdrfp4ncbpmkm@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal: Local indexes for partitioned table (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Proposal: Local indexes for partitioned table
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: