Re: Slow DROP INDEX - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Slow DROP INDEX
Date
Msg-id 000401c3f4e1$a6701c90$c19d87d9@LaptopDellXP
Whole thread Raw
In response to Re: Slow DROP INDEX  (Rod Taylor <pg@rbt.ca>)
List pgsql-hackers
>Rod Taylor
> On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> > Rod Taylor <pg@rbt.ca> writes:
> > > The real question is why does DROP INDEX take more than a couple
of
> > > seconds to complete? It is not held up by locked.
> >
> > AFAICS it shouldn't take any time to complete.  I think you're
mistaken
> > and it is blocking on a lock (it will want exclusive lock on the
table).
> > Everyone else will then queue up behind it.
> 
> I not convinced it is waiting on a lock. The queries on that table are
> very short (couple of milliseconds) -- but there are a ton of them.
All
> backends appear to be idle (pg_stat_activity with command shown) when
we
> start the drop and shortly after huge backups occur.

Could it be waiting on a lock held on something other than the target
table itself?

A system catalog table, either for access right or optimization? Maybe
the drop index lock is the same as the drop table lock (and perhaps it
shouldn't be).

May not be the case...but the answer should be interesting.

Hope it helps, Simon Riggs



pgsql-hackers by date:

Previous
From: markw@osdl.org
Date:
Subject: Re: Proposed Query Planner TODO items
Next
From: "Simon Riggs"
Date:
Subject: Re: [PATCHES] update i386 spinlock for hyperthreading