| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-03 09:10:54 |
| Message-ID: | 1133601054.2906.713.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2005-12-02 at 17:45 -0500, Tom Lane wrote:
> 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.
Those are technical difficulties that I believe can be solved.
Greg was right: online index builds are very useful (for us).
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2005-12-03 09:21:37 | Re: Optimizer oddness, possibly compounded in 8.1 |
| Previous Message | Simon Riggs | 2005-12-03 08:56:41 | Re: Spam 508 |