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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: REGRESS_OPTS default
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: synchronized snapshots