>Rod Taylor
> On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> > Rod Taylor <[EMAIL PROTECTED]> 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
Rod Taylor <[EMAIL PROTECTED]> writes:
> 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 hug
ECTED] Behalf Of Rod Taylor
Sent: Monday, February 16, 2004 10:56 AM
To: Tom Lane
Cc: PostgreSQL Development
Subject: Re: [HACKERS] Slow DROP INDEX
On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > The real question is why does DROP INDEX take m
On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> 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 i
Rod Taylor <[EMAIL PROTECTED]> 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
I have an IO congested database (PostgreSQL 7.2) with too many
(overlapping) indexes, so the obvious solution is to drop them.
DROP INDEX seems to want to take several minutes to complete, which
causes a backup of clients and me to eventually abort the process to let
all the backed up queries go t
