From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Fuhr <mike@fuhr.org>
Cc: Merlin Moncure <merlin.moncure@rcsonline.com>
Cc: pgsql-performance@postgresql.org, Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
Subject: Re: How much expensive are row level statistics?
Date: Mon, 12 Dec 2005 22:20:45 -0500
Message-ID: <1667.1134444045@sss.pgh.pa.us> (raw)
In-Reply-To: <20051213010751.GA63416@winnie.fuhr.org>
References: <6EE64EF3AB31D5448D0007DD34EEB3417DDAC9@Herge.rcsinc.local>
<2506.1134428461@sss.pgh.pa.us>
<20051213010751.GA63416@winnie.fuhr.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, mike@fuhr.org, merlin.moncure@rcsonline.com, carlosbenkendorf@yahoo.com.br
Subject: Re: How much expensive are row level statistics?
In-Reply-To: <1667.1134444045@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox