Re: pgsql/src/backend/access/transam (xact.c) - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql/src/backend/access/transam (xact.c)
Date
Msg-id 2434.973817210@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql/src/backend/access/transam (xact.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pgsql/src/backend/access/transam (xact.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-committers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I thought there were some cases where looking up the index on pg_index
> lead to an infinite recursion.  Maybe that is gone now.

No, that behavior is still there, and the special-case code for it
is still there in catcache.c (I did try taking it out just to see
what would happen ... sure 'nuff, infinite recursion).

But the routines in indexing.c weren't bringing anything to the party,
except for a restatement of the scankeys needed for various system
indexes.  And the syscache has that same info already.  Everytime we did
a tuple fetch for a syscache, the routine in indexing.c was redoing
ScanKeyEntryInitialize() calls to recompute the same scankey information
already present in the syscache.  Waste of time, particularly the
fmgr_info() call.

I left a couple of the indexing.c routines in place because there were
hardwired calls to them in relcache.c.  But most of them aren't needed,
and they certainly aren't valuable enough to expect people to make
another one everytime they make a new syscache ...

            regards, tom lane

pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgsql/src/backend/access/transam (xact.c)
Next
From: tgl@postgresql.org
Date:
Subject: pgsql/src/backend/catalog (indexing.c)