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

From Bruce Momjian
Subject Re: pgsql/src/backend/access/transam (xact.c)
Date
Msg-id 200011100055.TAA20264@candle.pha.pa.us
Whole thread Raw
In response to Re: pgsql/src/backend/access/transam (xact.c)  (Tom Lane <tgl@sss.pgh.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).

OK, I understand.

>
> 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 ...

Yes, I see that now.  Very nice.  It was a pain to update for new
caches.


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-committers by date:

Previous
From: tgl@postgresql.org
Date:
Subject: pgsql/src/include/catalog (indexing.h)
Next
From: tgl@postgresql.org
Date:
Subject: pgsql/src/include/utils (catcache.h)