From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should I implement DROP INDEX CONCURRENTLY? |
Date: | 2011-08-24 18:33:46 |
Message-ID: | CAHyXU0w4sKtbk_HzkcvJLJ80ZM41mSBAmRxD1bNz6w93d+6wGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> Hello list,
>
> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
> recently when frobbing around some indexes I realized that there is no
> equivalent for DROP INDEX, and this is a similar but lesser problem
> (as CREATE INDEX takes much longer), as DROP INDEX takes an ACCESS
> EXCLUSIVE lock on the parent table while doing the work to unlink
> files, which nominally one would think to be trivial, but I assure you
> it is not at times for even indexes that are a handful of gigabytes
> (let's say ~=< a dozen). By non-trivial, I mean it can take 30+
> seconds, but less than a couple of minutes. The storage layer
> (starting from the higher levels of abstraction) are XFS, a somewhat
> trivial lvm setup, mdraid (8-ways), Amazon EBS (NBD?).
Are you sure that you are really waiting on the time to unlink the
file? there's other stuff going on in there like waiting for lock,
plan invalidation, etc. Point being, maybe the time consuming stuff
can't really be deferred which would make the proposal moot.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-08-24 18:38:42 | Re: synchronized snapshots |
Previous Message | Peter Eisentraut | 2011-08-24 18:30:10 | Re: REGRESS_OPTS default |