"Steven Flatt" <steven(dot)flatt(at)gmail(dot)com> writes:
>> The fly in the ointment is that after collecting the pg_index definition
>> of the index, plancat.c also wants to know how big it is --- it calls
> Why do we even need to consider calling RelationGetNumberOfBlocks or looking
> at the pg_class.relpages entry? My understanding of the expected behaviour
> is that while a reindex is happening, all queries run against the parent
> table are planned as though the index isn't there (i.e. it's unusable).
Where in the world did you get that idea?
If we had a REINDEX CONCURRENTLY it might work that way. A normal
REINDEX cannot "mark" anything because it runs within a single
transaction; there is no way that it can emit any catalog changes
that will be visible before it's over.
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Luke Lonergan||Date: 2007-08-24 16:20:28|
|Subject: Re: partitioned table and ORDER BY indexed_field DESC
|Previous:||From: Steven Flatt||Date: 2007-08-24 14:22:38|
|Subject: Re: When/if to Reindex|