| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jochem van Dieten <jochemd(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: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) |
| Date: | 2005-12-07 00:32:30 |
| Message-ID: | 87pso9iw69.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> The scenario where concurrent create index command is be needed is 24/7
> OLTP databases, which can't be taken down for maintenance. Usully they
> can be arranged to tolerate postponing a few transactions for one
> second.
Well, the dominant defining characteristic of "OLTP" is precisely that you do
*not* have under your control the timing requirements and can't make such
arrangements. That is, you have to process requests as fast as they come in
whatever that might be.
But that said, realistically *any* solution has to obtain a lock at some time
to make the schema change. I would say pretty much any O(1) (constant time)
outage is at least somewhat acceptable as contrasted with the normal index
build which locks out other writers for at least O(n lg n) time. Anything on
the order of 100ms is probably as good as it gets here.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2005-12-07 01:43:30 | Re: Oddity with extract microseconds? |
| Previous Message | Tom Lane | 2005-12-07 00:24:43 | Re: [GENERAL] 8.1, OID's and plpgsql |