Re: Slow DROP INDEX
От | Simon Riggs |
---|---|
Тема | Re: Slow DROP INDEX |
Дата | |
Msg-id | 000401c3f4e1$a6701c90$c19d87d9@LaptopDellXP обсуждение исходный текст |
Ответ на | Re: Slow DROP INDEX (Rod Taylor <pg@rbt.ca>) |
Список | 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 по дате отправления: