| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Reducing relation locking overhead |
| Date: | 2005-12-02 06:44:08 |
| Message-ID: | 87iru8f16v.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Surely in the real world REINDEX is run so rarely compared to all those other
> operations it'd be a win...
It's not a question of frequency. We're not talking about something like a 10%
performance loss. You're talking about whether REINDEX is useful at all.
Consider installations where REINDEX will require shutting down business
critical operations for days...
It was a *major* new feature that many people were waiting for when Oracle
finally implemented live CREATE INDEX and REINDEX. The ability to run create
an index without blocking any operations on a table, even updates, was
absolutely critical for 24x7 operation.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Trent Shipley | 2005-12-02 07:06:28 | Re: generalizing the planner knobs |
| Previous Message | Greg Stark | 2005-12-02 06:40:06 | Re: Fork-based version of pgbench |