Re: disabling an index without deleting it?

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Peter Koczan" <pjkoczan(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: disabling an index without deleting it?
Date: 2008-02-27 05:16:54
Message-ID: dcc563d10802262116q54b0541fj1aa10821e2255419@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> writes:
> > 2008/2/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> >> No, what makes you think that? The index won't change at all in the
> >> above example. The major problem is, as Scott says, that DROP INDEX
> >> takes exclusive lock on the table so any other sessions will be locked
> >> out of it for the duration of your test query.
>
> > Why is the exclusive lock not taken later, so that this method can be
> > used reasonably risk-free on production systems?
>
> Er, later than what? Once the DROP is pending, other transactions can
> hardly safely use the index for lookups, and what should they do about
> insertions?

I see what you're saying. Sadly, my dreams of drop index concurrently
appear dashed.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Bertheau 2008-02-27 05:29:55 Re: disabling an index without deleting it?
Previous Message Tom Lane 2008-02-27 04:48:49 Re: disabling an index without deleting it?