Re: "slow" queries
От | Scott Marlowe |
---|---|
Тема | Re: "slow" queries |
Дата | |
Msg-id | dcc563d10903021359n2824c763r36f31abb2063a403@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "slow" queries (Tim Bunce <Tim.Bunce@pobox.com>) |
Список | pgsql-performance |
On Mon, Mar 2, 2009 at 2:24 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: > On Mon, Mar 02, 2009 at 02:29:31PM -0500, Tom Lane wrote: >> Brian Cox <brian.cox@ca.com> writes: >> > select locktype,database,relation,virtualxid,virtualtransaction,pid,mode >> > from pg_locks order by mode; >> >> If you hadn't left out the "granted" column we could be more sure, >> but what it looks like to me is the DROP (pid 13842) is stuck behind >> the <IDLE> transaction (pid 13833). In particular these two rows of >> pg_locks look like a possible conflict: >> >> > relation | 26472437 | 26472508 | | 15/69749 >> > | 13842 | AccessExclusiveLock >> >> > relation | 26472437 | 26472508 | | 11/131 >> > | 13833 | AccessShareLock > > Would it be possible to write a stored procedure that would read > pg_locks, and other relevant tables, and list what's blocking what > in a simplified form? I'm sure a query could use just connect by from tablefuncs, or WITH under 8.4 and get it.
В списке pgsql-performance по дате отправления: