From: Tom Lane <tgl@sss.pgh.pa.us>
To: Merlin Moncure <merlin.moncure@rcsonline.com>
Cc: Michael Fuhr <mike@fuhr.org>
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 18:01:01 -0500
Message-ID: <2506.1134428461@sss.pgh.pa.us> (raw)
In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3417DDAC9@Herge.rcsinc.local>
References: <6EE64EF3AB31D5448D0007DD34EEB3417DDAC9@Herge.rcsinc.local>
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> The cost depends on your usage patterns. I did tests with one of
>> my applications and saw no significant performance difference for
>> simple selects, but a series of insert/update/delete operations ran
>> about 30% slower when block- and row-level statistics were enabled
>> versus when the statistics collector was disabled.
> That approximately confirms my results, except that the penalty may even
> be a little bit higher in the worst-case scenario. Row level stats hit
> the hardest if you are doing 1 row at a time operations over a
> persistent connection.
IIRC, the only significant cost from enabling stats is the cost of
transmitting the counts to the stats collector, which is a cost
basically paid once at each transaction commit. So short transactions
will definitely have more overhead than longer ones. Even for a really
simple transaction, though, 30% seems high --- the stats code is
designed deliberately to minimize the penalty.
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, merlin.moncure@rcsonline.com, mike@fuhr.org, carlosbenkendorf@yahoo.com.br
Subject: Re: How much expensive are row level statistics?
In-Reply-To: <2506.1134428461@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