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

Re: When/if to Reindex

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "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 20:06:53
Message-ID: 876434zogy.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-performance
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com> writes:
>> So, can we simply trust what's in pg_class.relpages and ignore looking
>> directly at the index?
>
> No, we can't.  In the light of morning I remember more about the reason
> for the aforesaid patch: it's actually unsafe to read the pg_class row
> at all if you have not got lock on the index.  We are reading with
> SnapshotNow in order to be sure we see up-to-date info, and that means
> that a concurrent update of the row (eg, for REINDEX to report the new
> relfilenode) can have the following behavior:

Should reindex be doing an in-place update? Don't we have to do in-place
updates for other system catalogs which are read in snapshotnow for precisely
the same reasons?

Alternatively, why does the planner need access to the pg_class entry and not
just the pg_index record?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-performance by date

Next:From: Bill MoranDate: 2007-08-24 20:41:44
Subject: Re: significant vacuum issues - looking for suggestions
Previous:From: Kevin KempterDate: 2007-08-24 19:57:23
Subject: significant vacuum issues - looking for suggestions

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