> As near as I can tell, the bogus data is the fault of the relation
> cache. Info about pg_class_oid_index and a couple of other indexes on
> system relations is preloaded into the relcache and locked there on
> startup --- and it is *not* coming from pg_class, but from an
> initialization file that evidently was made when these system tables
> were empty.
>
> Bottom line is that optimization estimates that involve these critical
> system indexes will be wrong. That's not a show-stopper, but it seems
> to me that it must be costing us performance somewhere along the line.
> I'd like to see if it can be fixed.
>
> Does anyone understand:
>
> (a) why does the relcache need an initialization file for the system
> index cache entries in the first place? If I'm reading the code
> correctly, it is able to build the initialization file from the info
> in pg_class, so one would think it'd be better to just do that during
> every startup and forget the initialization file.
The problem is cicurular too. Without those entries in the cache, the
system can't do the lookups of the real tables.
> (b) if we can't just get rid of the init file, how about dropping and
> rebuilding it at the end of the initdb process (after template1 has
> been vacuumed)? Then at least it'd show a size of a few hundred for
> pg_class, instead of zero.
You can't drop them or you could never recreate them. Why does the
vacuum analyze at the end of initdb not fix this? Is this because the
cache bypasses pg_class and returns the hardcoded rows?
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026