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: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:35:44
Message-ID: 43DE2440.4020409@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On 1/27/2006 10:53 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
> 
>> I think this is the fault of the stats system design.  AFAICT from a
>> quick look at the code, inserted/updated/deleted tuples are reported
>> to the collector in the same way regardless of whether the sending
>> transaction committed or rolled back.  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.

It's not a bug. More some "don't bother" attitude. The stats were not 
intended to be precise. Their sole purpose at the time of design and 
development was to give clues for missing or useless indexes, identify 
candidates to move onto different spindles and things like autovacuum. 
If the number of aborts you're riding significantly disturbs your 
statistic collection, you should look at some design issues with your 
own application instead.


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 #

In response to

pgsql-hackers by date

Next:From: Jan WieckDate: 2006-01-30 14:40:44
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM
Previous:From: Christopher Kings-LynneDate: 2006-01-30 14:01:58
Subject: Re: Want to add to contrib.... xmldbx

pgsql-general by date

Next:From: Jan WieckDate: 2006-01-30 14:40:44
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM
Previous:From: David LangDate: 2006-01-30 14:32:24
Subject: looking for consulting

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