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

Re: When/if to Reindex

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com>
Cc: "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, "Vivek Khera" <vivek(at)khera(dot)org>, "Pgsql performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: When/if to Reindex
Date: 2007-08-24 16:15:25
Message-ID: 1759.1187972125@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"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
>> RelationGetNumberOfBlocks.

> 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

Responses

pgsql-performance by date

Next:From: Luke LonerganDate: 2007-08-24 16:20:28
Subject: Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
Previous:From: Steven FlattDate: 2007-08-24 14:22:38
Subject: Re: When/if to Reindex

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