Planned simplification of catalog index updates
От | Tom Lane |
---|---|
Тема | Planned simplification of catalog index updates |
Дата | |
Msg-id | 29401.1028335266@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Planned simplification of catalog index updates
Re: Planned simplification of catalog index updates Re: Planned simplification of catalog index updates |
Список | pgsql-hackers |
I count about seventy occurrences of this code pattern: /* keep system catalog indices current */ if (RelationGetForm(pg_rewrite_desc)->relhasindex) { Relation idescs[Num_pg_rewrite_indices]; CatalogOpenIndices(Num_pg_rewrite_indices, Name_pg_rewrite_indices, idescs); CatalogIndexInsert(idescs,Num_pg_rewrite_indices, pg_rewrite_desc, ruletup); CatalogCloseIndices(Num_pg_rewrite_indices,idescs); } I believe this could be simplified to something like CatalogUpdateIndexes(Relation, HeapTuple, indexnamelist_constant, indexcount_constant); with essentially no speed penalty. An even more radical approach is to get rid of the hardwired index name lists in indexing.h, and instead expect CatalogOpenIndices to make use of the index OID lists that are maintained by the relcache (since 7.1 or so). Then the typical call would reduce to CatalogUpdateIndexes(Relation, HeapTuple); This would simplify development/maintenance at the cost of a small amount of CPU time building the index OID list whenever it wasn't already cached. (OTOH ... I'm unsure whether opening an index by OID is any faster than opening it by name, but it's certainly plausible that it might be --- so we could find we buy back the time spent building relcache index lists by making the actual index open step quicker.) Comments? I want to do the first step in any case, but I'm not sure about eliminating the index name lists. regards, tom lane
В списке pgsql-hackers по дате отправления: