Re: disabling an index without deleting it? - Mailing list pgsql-performance

From Markus Bertheau
Subject Re: disabling an index without deleting it?
Date
Msg-id 684362e10802261848j79686752k6dfbe032e985b131@mail.gmail.com
Whole thread Raw
In response to Re: disabling an index without deleting it?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: disabling an index without deleting it?
Re: disabling an index without deleting it?
List pgsql-performance
2008/2/27, Tom Lane <tgl@sss.pgh.pa.us>:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>  > "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>
> >> begin;
>  >> drop index abc_dx;
>  >> select ....
>  >> rollback;
>  >>
>  >> and viola, your index is still there.  note that there are likely some
>  >> locking issues with this, so be careful with it in production.  But on
>  >> a test box it's a very easy way to test various indexes.
>
>  > Wouldn't you also bloat the index?
>
>
> 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? From what I
understand the later would be either a statement that would
(potentially) be modifying the index, like an UPDATE or an INSERT, or
actual transaction commit. If none of these occur and the transaction
is rollbacked, the exclusive lock doesn't have to be taken at all.

Markus

--
Markus Bertheau
Blog: http://www.bluetwanger.de/blog/

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: LISTEN / NOTIFY performance in 8.3
Next
From: "Scott Marlowe"
Date:
Subject: Re: disabling an index without deleting it?