Re: stats for failed transactions (was Re: [GENERAL] VACUUM

On 1/27/2006 10:56 AM, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> Tom Lane wrote:
>>> I think this is unquestionably
>>> a bug, at least for autovacuum's purposes --- though it might be OK
>>> for the original intent of the stats system, which was simply to track
>>> activity levels.
>>>
>>> Any thoughts about how it ought to work?
>
>> I don't remember exactly how it works -- I think the activity (insert,
>> update, delete) counters are kept separately from commit/rollback
>> status, right? Maybe we should keep three separate counters: "current
>> transaction counters" and "counters for transactions that were
>> aborted/committed". We only send the latter counts, and the former are
>> added to them when the transaction ends.
>
> My question was at a higher level, actually: *what* should we be
> counting?
>
> I think doubling the number of counters in the stats system, which is
> what you seem to be proposing, is probably not acceptable --- we've
> already got a problem with the stats file becoming unreasonably bulky.
> We need to figure out exactly which counts there is adequate reason
> to be tracking.
>
> I don't, for instance, see any percentage in tracking block-level I/O
> operations separately for committed and rolled-back transactions.
> Those numbers are certainly things you watch only for total activity,
> and a failed xact is just as much system load as a committed one.

Right.

The problem is that different questions need different counting
semantics. If one looks at an application profile, he wants to know how
many inserts, updates and deletes the app has issued, probably
regardless of the final transaction outcome. But for autovac he wants to
be able to figure out how many dead tuples there would be, so for that
purpose inserts in a rolled back xact would count as ins+del where
deletes would not count at all.

Jan

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