Re: Update blocking a select count(*)?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Benedict Holland" <benedict(dot)m(dot)holland(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Update blocking a select count(*)?
Date: 2012-06-15 20:38:39
Message-ID: 4FDB56FF0200002500048510@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Benedict Holland <benedict(dot)m(dot)holland(at)gmail(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Віталій Тимчишин 2012-06-18 13:47:42 correlated exists with join is slow.
Previous Message Benedict Holland 2012-06-15 20:29:02 Re: Update blocking a select count(*)?