DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=Yahoo.com;
	h=Received:Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=qiBgzOIl0BqwFbQoPS4j4rno6Vnu4eRFKg1654ni8BPnfBPvqT6+jRooWhUInAsMMxytlHSrVdahOUIhCkY9C+EH4LFgVwNuU500W7j6hj4z+6x3AskWnz/jYPAxGxbFV7jP27PahHJ0xLDH3M1sxpyIMi++Bt3qMeVVIb8DoBE=
	;
Message-ID: <43B9F861.5040207@Yahoo.com>
Date: Mon, 02 Jan 2006 23:06:57 -0500
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: Stats collector performance improvement
References: <200601021840.k02Ieed21704@candle.pha.pa.us>
	<11924.1136233224@sss.pgh.pa.us>
In-Reply-To: <11924.1136233224@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 1/2/2006 3:20 PM, Tom Lane wrote:

> [ moving to -hackers ]
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I did some research on this because the numbers Tom quotes indicate there
>> is something wrong in the way we process stats_command_string
>> statistics.
>> [ ... proposed patch that seems pretty klugy to me ... ]
> 
> I wonder whether we shouldn't consider something more drastic, like
> getting rid of the intermediate stats buffer process entirely.
> 
> The original design for the stats communication code was based on the
> premise that it's better to drop data than to make backends wait on

The original design was geared towards searching for useless/missing 
indexes and tuning activity like that. This never happened, but instead 
people tried to use it as a reliable debugging or access statistics aid 
... which is fine but not what it originally was intended for.

So yes, I think looking at what it usually is used for, a message 
passing system like SysV message queues (puke) or similar would do a 
better job.


Jan

> the stats collector.  However, as things have turned out I think this
> notion is a flop: the people who are using stats at all want the stats
> to be reliable.  We've certainly seen plenty of gripes from people who
> are unhappy that backend-exit messages got dropped, and anyone who's
> using autovacuum would really like the tuple update counts to be pretty
> solid too.
> 
> If we abandoned the unreliable-communication approach, could we build
> something with less overhead?
> 
> 			regards, tom lane


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #