Re: When/if to Reindex

On 8/24/07, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> wrote:
>
> Tom Lane wrote:
> >
> > 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
> > RelationGetNumberOfBlocks. And that absolutely does look at the
> > physical storage, which means it absolutely is unsafe to do in parallel
> > with a REINDEX that will be dropping the old physical storage at some
> > point.
>
> A suggestion that seems a bit like a leap backwards in time - maybe just
> use the pg_class.relpages entry for the index size?

Just throwing this out there (looking from a higher level)...

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).
This may/will result in sub-optimal query plans, but the point is that
reindex never blocks readers. Not sure if from an implementation standpoint
it's easy to mark an index as "being reindexed" in which case the planner
should just skip it.

Steve