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

Re: Reducing relation locking overhead

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Maxwell <gmaxwell(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing relation locking overhead
Date: 2005-12-02 22:45:10
Message-ID: 8413.1133563510@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> CREATE INDEX uses SnapshotAny, so the scan that feeds the build could
> easily include rows added after the CREATE INDEX started. When the scan
> was exhausted we could mark that last TID and return to it after the
> sort/build.

And do what?  This has nothing to do with the fundamental problem of
never being able to catch up unless you can upgrade your lock to exclude
writes.  What's worse, once you have excluded writes you have to rescan
the entire table to be sure you haven't missed anything.  So in the
scenarios where this whole thing is actually interesting, ie enormous
tables, you're still talking about a fairly long interval with writes
locked out.  Maybe not as long as a complete REINDEX, but long.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-12-02 22:47:35
Subject: Spam 508
Previous:From: Andrew DunstanDate: 2005-12-02 22:45:05
Subject: Re: Optional postgres database not so optional in 8.1

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