Planned simplification of catalog index updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Planned simplification of catalog index updates
Date: 2002-08-03 00:41:06
Message-ID: 29401.1028335266@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-03 00:44:27 Re: PITR, checkpoint, and local relations
Previous Message Mikheev, Vadim 2002-08-03 00:31:04 Re: PITR, checkpoint, and local relations