Planned simplification of catalog index updates

Поиск
Список
Период
Сортировка
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 по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: Re: PITR, checkpoint, and local relations
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PITR, checkpoint, and local relations