Re: Planned simplification of catalog index updates

I said:
> 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.)

Indeed, it seems this *is* faster. I used the regression tests as a
crude benchmark --- pg_bench wouldn't help since it doesn't do any
catalog updates in the inner loop. Over ten runs of "make installcheck"
on a RH 7.2 system, yesterday's CVS tip gave the following results for
elapsed real time in seconds:

min | max | avg | stddev
-------+-------+------------------+-------------------
26.18 | 28.12 | 27.3590909090909 | 0.767247737637082

With modifications to do all system catalog index updates as above,
I instead got:

min | max | avg | stddev
------+-------+--------+-------------------
24.3 | 26.72 | 25.833 | 0.674372959784605

So it seems to be a fairly reliable 5% win on the regression tests,
on top of being a lot simpler and more maintainable.

I'm pretty pleased, and will be committing this as soon as CVS tip
is back to a non-broken state ...

regards, tom lane