Date: Tue, 3 Jan 2006 10:35:56 -0600
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Qingqing Zhou <zhouqq@cs.toronto.edu>,
	pgsql-hackers@postgresql.org
Subject: Re: Stats collector performance improvement
Message-ID: <20060103163556.GH82560@pervasive.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1136281253.5052.113.camel@localhost.localdomain>
User-Agent: Mutt/1.5.11

On Tue, Jan 03, 2006 at 09:40:53AM +0000, Simon Riggs wrote:
> On Mon, 2006-01-02 at 16:48 -0500, Tom Lane wrote:
> 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. Pushing the statement to stats
> every time is just a big overhead. That suggests we should either have a
> pull or a deferred push (longer-than-X-secs) approach.

I would argue that minutes is too long, but of course this could be
user-adjustable. I suspect that even waiting just a second could be a
huge win, since this only matters if you're executing a lot of
statements and you won't be doing that if those statements are taking
more than a second or two to execute.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461