Re: pgsql/src/backend/access/transam (xact.c)
| От | Bruce Momjian |
|---|---|
| Тема | Re: pgsql/src/backend/access/transam (xact.c) |
| Дата | |
| Msg-id | 200011100055.TAA20264@candle.pha.pa.us обсуждение |
| Ответ на | Re: pgsql/src/backend/access/transam (xact.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: