From: | "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(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 02:48:06 |
Message-ID: | 684362e10802261848j79686752k6dfbe032e985b131@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2008/2/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-02-27 03:48:57 | Re: disabling an index without deleting it? |
Previous Message | Tom Lane | 2008-02-26 23:33:50 | Re: LISTEN / NOTIFY performance in 8.3 |