Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Optimizer fed bad data about some system-table indexes
Date: 1999-04-30 19:06:01
Message-ID: 29310.925499161@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1999-04-30 19:26:59
Subject: Re: [HACKERS] Optimizer fed bad data about some system-table indexes
Previous:From: Bruce MomjianDate: 1999-04-30 17:49:57
Subject: Re: [HACKERS] Optimizer fed bad data about some system-table indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group