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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-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

Browse pgsql-general by date

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

Browse pgsql-hackers by date

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