Re: [HACKERS] Optimizer fed bad data about some system-table indexes

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> (a) why does the relcache need an initialization file for the system
>> index cache entries in the first place?

> The problem is cicurular too.  Without those entries in the cache, the
> system can't do the lookups of the real tables.

But the init file is built on-the-fly the first time it is needed;
so it seems it can't be as circular as all that.  If we *really* needed
hardcoded data then it would have to be done more like the way the
standard entries in pg_class and other sys tables are made.  I think.

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

The vacuum analyze *does* fix the data that's in the pg_class entry
for the index.  Trouble is that the relcache entry for the index is
never read from pg_class; it's loaded from this never-updated init file.

One possible answer is to rewrite the init file as the final step of
a vacuum, using the just-updated pg_class data.  But I'm still not
convinced that we really need the init file at all...
        regards, tom lane