Tom Lane wrote:
>
> I spent the weekend fooling around trying to reduce the time needed to
> start a fresh backend. Profiling seemed to indicate that much of the
> time was going into loading entries into the relcache: relcache entry
> setup normally requires fetching rows from several different system
> catalogs. The obvious way to fix that is to preload entries somehow.
> It turns out we already have a mechanism for this (the pg_internal.init
> file), but it was only being used to preload entries for a few critical
> system indexes --- "critical" meaning "relcache/catcache initialization
> becomes an infinite recursion otherwise". I rearranged things so that
> pg_internal.init could cache entries for both plain relations and
> indexes, and then set it up to cache all the system catalogs and indexes
> that are referenced by catalog caches. (This is a somewhat arbitrary
> choice, but was easy to implement.)
While examining this issue I found the following change
about REINDEX.
Subject: [COMMITTERS] pgsql/src/backend catalog/index.c commands/ind
... Date: Mon, 19 Nov 2001 21:46:13 -0500 (EST) From: tgl@postgresql.org To: pgsql-committers@postgresql.org
CVSROOT: /cvsroot
Module name: pgsql
Changes by: tgl@postgresql.org 01/11/19 21:46:13
Modified files: src/backend/catalog: index.c src/backend/commands: indexcmds.c src/backend/tcop:
utility.c
Log message: Some minor tweaks of REINDEX processing: grab exclusivelock a little earlier, make error checks more
uniform.
The change on tcop/utility.c seems to inhibit the execution
of REINDEX of system indexes under postmaster which I allowed
except some system indexes in 7.1.
Please put it back in 7.2.1.
Inhibited relations are the indexes of the followings.
[Shared relations]
pg_database, pg_shadow, pg_group
[Nailed relations]
pg_class, pg_type, pg_attribute, pg_proc
There are some trial stuff to handle nailed relations
(mostly #ifdef'd ENABLE_REINDEX_NAILED_RELATIONS).
Especially setNewRelfilenode() unlinks the pg_internal.init
file in case the relation is nailed. However I don't rely
on the mechanism so much that I can't feel like removing the
#ifdef's.
regards,
Hiroshi Inoue
