Hi, I had some spare time tonight so I started a prototype to allow filtering the indexes that are processed using the REINDEX command, as Peter suggested in the parallel reindexdb thread [1].
I didn't want to spend too much time enjoying bison and adding new unreserved keywords, so for now I just implemented this syntax to start a discussion for this feature in the next commitfest: REINDEX ( FILTER = COLLATION ) [...] The FILTER clause can be used multiple times, each one is OR-ed with the ReindexStmt's option, so we could easily add a LIBC, ICU and other filters, also making COLLATION (or more realistically a better new keyword) an alias for (LIBC | ICU) for instance. The filtering is done at table level (with and without the concurrently option), so SCHEMA, DATABASE and SYSTEM automatically benefit from it. If this clause is used with a REINDEX INDEX, the statement errors out, as I don't see a valid use case for providing a single index name and asking to possibly filter it at the same time. Under the hood, the filtering is for now done in a single function by appending elements, not removing them. An empty oid list is created, all indexes belonging to the underlying relation are processed by the specific filter(s), and any index that fails to be discarded by at least one filter, even partially, is added to the final list. I also added some minimal documentation and regression tests. I'll add this patch to the next commitfest. [1] https://www.postgresql.org/message-id/7140716c-679e-a0b9-a273-b201329d8891%402ndquadrant.com
reindex_filter-v1.diff
Description: Binary data
