Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Date
Msg-id 87pso9iw69.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing  (Hannu Krosing <hannu@skype.net>)
Responses Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
List pgsql-hackers
Hannu Krosing <hannu@skype.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] 8.1, OID's and plpgsql
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Oddity with extract microseconds?