Skip site navigation (1) Skip section navigation (2)

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

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM
Date: 2006-01-30 14:40:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
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.


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.


# 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 #

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-30 15:00:20
Subject: Re: Weirdness with =?
Previous:From: Jan WieckDate: 2006-01-30 14:35:44
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM

pgsql-general by date

Next:From: Sim ZacksDate: 2006-01-30 14:51:21
Subject: Re: schema rename sequence issue
Previous:From: Jan WieckDate: 2006-01-30 14:35:44
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group