Re: Update blocking a select count(*)?
От | Kevin Grittner |
---|---|
Тема | Re: Update blocking a select count(*)? |
Дата | |
Msg-id | 4FDB56FF0200002500048510@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Update blocking a select count(*)? (Benedict Holland <benedict.m.holland@gmail.com>) |
Список | pgsql-performance |
Benedict Holland <benedict.m.holland@gmail.com> wrote: > I ran the scripts on the page and both returned empty (though I > have queries running and currently nothing blocks). I don't know > what they should have been. It only shows information on blocking, so the list should be empty when there is none. :-) If it works as intended, it would have shown the chain of blocking, from the update to the alter to the select. > The output was from PgAdmin3 which is a UI for postgres. I assume > that they get this queried information from something inside of > postgres as I can't imagine the query tool doing something other > than querying the database for specs. They are probably doing something internally which is somewhat similar to the recursive query on that page. It sounds like when there is a chain or tree of blocking, they show the process at the front of the parade, rather than the immediate blocker. I can't say that's right or wrong, but it should be documented so that people can understand what they're looking at. Even better would be to make a nice graphical tree of the blocking, but that would be getting pretty fancy. :-) -Kevin
В списке pgsql-performance по дате отправления: