From: Hannu Krosing <hannu@skype.net>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Qingqing Zhou <zhouqq@cs.toronto.edu>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Stats collector performance improvement
Date: Tue, 03 Jan 2006 23:42:53 +0200
Message-ID: <1136324574.4256.17.camel@localhost.localdomain> (raw)
In-Reply-To: <1136281253.5052.113.camel@localhost.localdomain>
References: <200601021840.k02Ieed21704@candle.pha.pa.us>
<11924.1136233224@sss.pgh.pa.us>
<dpc4cg$lm6$1@news.hub.org>
<12503.1136238525@sss.pgh.pa.us>
<1136281253.5052.113.camel@localhost.localdomain>
Ühel kenal päeval, T, 2006-01-03 kell 09:40, kirjutas Simon Riggs:
> We can also save lots of cycles on the current statement overhead, which
> is currently the worst part of the stats, performance-wise. That
> definitely needs redesign. AFAICS we only ever need to know the SQL
> statement via the stats system if the statement has been running for
> more than a few minutes - the main use case is for an admin to be able
> to diagnose a rogue or hung statement.
Interestingly I use pg_stat_activity view to watch for stuck backends,
"stuck" in the sense that they have not noticed when client want away
and are now waitin the TCP timeout to happen. I query for backends which
have been in "<IDLE>" state for longer than XX seconds. I guess that at
least some kind of indication for this should be available.
Of course this would be much less of a problem if there was a
possibility for sime kind of keepalive system to detect when
client/frontend goes away.
> Pushing the statement to stats
> every time is just a big overhead. That suggests we should either have a
> pull
I could live with "push", where pg_stat_activity would actually ask each
live backend for its "current query". This surely happens less often
than queries are performed (up to few thousand per sec)
-------------
Hannu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: hannu@skype.net, simon@2ndquadrant.com, tgl@sss.pgh.pa.us, zhouqq@cs.toronto.edu, pgsql-hackers@postgresql.org
Subject: Re: Stats collector performance improvement
In-Reply-To: <1136324574.4256.17.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox