To: "Qingqing Zhou" <zhouqq@cs.toronto.edu>
cc: pgsql-hackers@postgresql.org
Subject: Re: Stats collector performance improvement 
In-reply-to: <dpc4cg$lm6$1@news.hub.org> 
References: <200601021840.k02Ieed21704@candle.pha.pa.us>
	<11924.1136233224@sss.pgh.pa.us> <dpc4cg$lm6$1@news.hub.org>
Comments: In-reply-to "Qingqing Zhou" <zhouqq@cs.toronto.edu>
	message dated "Mon, 02 Jan 2006 16:03:20 -0500"
Date: Mon, 02 Jan 2006 16:48:45 -0500
Message-ID: <12503.1136238525@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> AFAICS if we can maintain the stats counts solid, then it may hurt 
> performance dramatically. Think if we maintain 
> pgstat_count_heap_insert()/pgstat_count_heap_delete() pretty well, then we 
> get a replacement of count(*).

Not at all.  For one thing, the stats don't attempt to maintain
per-transaction state, so they don't have the MVCC issues of count(*).
I'm not suggesting any fundamental changes in what is counted or when.

The two compromises that were made in the original stats design to make
it fast were (1) stats updates lag behind reality, and (2) some updates
may be missed entirely.  Now that we have a couple of years' field
experience with the code, it seems that (1) is acceptable for real usage
but (2) not so much.  And it's not even clear that we are buying any
performance gain from (2), considering that it's adding the overhead of
passing the data through an extra process.

			regards, tom lane