Planned simplification of catalog index updates - Mailing list pgsql-hackers

From Tom Lane
Subject Planned simplification of catalog index updates
Date
Msg-id 29401.1028335266@sss.pgh.pa.us
Whole thread Raw
Responses Re: Planned simplification of catalog index updates  (Rod Taylor <rbt@zort.ca>)
Re: Planned simplification of catalog index updates  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Planned simplification of catalog index updates  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: Re: PITR, checkpoint, and local relations
Next
From: Bruce Momjian
Date:
Subject: Re: PITR, checkpoint, and local relations