Re: Should I implement DROP INDEX CONCURRENTLY?
От | Merlin Moncure |
---|---|
Тема | Re: Should I implement DROP INDEX CONCURRENTLY? |
Дата | |
Msg-id | CAHyXU0w4sKtbk_HzkcvJLJ80ZM41mSBAmRxD1bNz6w93d+6wGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Should I implement DROP INDEX CONCURRENTLY? (Daniel Farina <daniel@heroku.com>) |
Ответы |
Re: Should I implement DROP INDEX CONCURRENTLY?
|
Список | pgsql-hackers |
On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina <daniel@heroku.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
В списке pgsql-hackers по дате отправления: