Skip site navigation (1) Skip section navigation (2)

Re: Stats collector performance improvement

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Stats collector performance improvement
Date: 2006-01-03 21:42:53
Message-ID: 1136324574.4256.17.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patchespgsql-performance
Ü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)


In response to


pgsql-performance by date

Next:From: Greg StarkDate: 2006-01-03 23:28:34
Subject: Re: Stats collector performance improvement
Previous:From: Bruce MomjianDate: 2006-01-03 16:43:23
Subject: Re: Stats collector performance improvement

pgsql-hackers by date

Next:From: Bruno Wolff IIIDate: 2006-01-03 22:31:40
Subject: Re: Why don't we allow DNS names in pg_hba.conf?
Previous:From: igDate: 2006-01-03 21:31:58
Subject: Windows Installer Bug

pgsql-patches by date

Next:From: Neil ConwayDate: 2006-01-03 23:00:13
Subject: Re: TODO item: list prepared queries
Previous:From: Tom LaneDate: 2006-01-03 20:47:04
Subject: Re: TODO item: list prepared queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group