Обсуждение: pgsql/src/backend/access/transam (xact.c)

  Date: Thursday, November  9, 2000 @ 19:33:08
Author: tgl

Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/access/transam
     from hub.org:/home/projects/pgsql/tmp/cvs-serv74599/src/backend/access/transam

Modified Files:
    xact.c

-----------------------------  Log Message  -----------------------------

Clean up syscache so that recursive invocation is safe, and remove error
message about recursive use of a syscache.  Also remove most of the
specialized indexscan routines in indexing.c --- it turns out that
catcache.c is perfectly able to perform the indexscan for itself,
in fact has already looked up all the information needed to do so!
This should be faster as well as needing far less boilerplate code.

>   Date: Thursday, November  9, 2000 @ 19:33:08
> Author: tgl
>
> Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/access/transam
>      from hub.org:/home/projects/pgsql/tmp/cvs-serv74599/src/backend/access/transam
>
> Modified Files:
>     xact.c
>
> -----------------------------  Log Message  -----------------------------
>
> Clean up syscache so that recursive invocation is safe, and remove error
> message about recursive use of a syscache.  Also remove most of the
> specialized indexscan routines in indexing.c --- it turns out that
> catcache.c is perfectly able to perform the indexscan for itself,
> in fact has already looked up all the information needed to do so!
> This should be faster as well as needing far less boilerplate code.

I thought there were some cases where looking up the index on pg_index
lead to an infinite recursion.  Maybe that is gone now.


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

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

> 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