X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 86B709DCCC2
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 12 Dec 2005 23:20:43 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 96604-08
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 12 Dec 2005 23:20:48 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 64A3A9DCC87
	for <pgsql-performance@postgresql.org>;
	Mon, 12 Dec 2005 23:20:41 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jBD3KjYY001668;
	Mon, 12 Dec 2005 22:20:45 -0500 (EST)
To: Michael Fuhr <mike@fuhr.org>
cc: Merlin Moncure <merlin.moncure@rcsonline.com>,
	pgsql-performance@postgresql.org,
	Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
Subject: Re: How much expensive are row level statistics? 
In-reply-to: <20051213010751.GA63416@winnie.fuhr.org> 
References: <6EE64EF3AB31D5448D0007DD34EEB3417DDAC9@Herge.rcsinc.local>
	<2506.1134428461@sss.pgh.pa.us>
	<20051213010751.GA63416@winnie.fuhr.org>
Comments: In-reply-to Michael Fuhr <mike@fuhr.org>
	message dated "Mon, 12 Dec 2005 18:07:51 -0700"
Date: Mon, 12 Dec 2005 22:20:45 -0500
Message-ID: <1667.1134444045@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.003 required=5 tests=[AWL=0.003]
X-Spam-Score: 0.003
X-Spam-Level: 
X-Archive-Number: 200512/308
X-Sequence-Number: 16129

Michael Fuhr <mike@fuhr.org> writes:
> Further tests show that for this application
> the killer is stats_command_string, not stats_block_level or
> stats_row_level.

I tried it with pgbench -c 10, and got these results:
	41% reduction in TPS rate for stats_command_string
	9% reduction in TPS rate for stats_block/row_level (any combination)

strace'ing a backend confirms my belief that stats_block/row_level send
just one stats message per transaction (at least for the relatively
small number of tables touched per transaction by pgbench).  However
stats_command_string sends 14(!) --- there are seven commands per
pgbench transaction and each results in sending a <command> message and
later an <IDLE> message.

Given the rather lackadaisical way in which the stats collector makes
the data available, it seems like the backends are being much too
enthusiastic about posting their stats_command_string status
immediately.  Might be worth thinking about how to cut back the
overhead by suppressing some of these messages.

			regards, tom lane