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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: stats for failed transactions (was Re: [GENERAL] VACUUM Question)
Date: 2006-01-28 16:13:36
Message-ID: 11969.1138464816@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> Tom Lane wrote:
>> the only full solution will involve backends doing some extra work at
>> subtransaction commit/abort so that they can report properly classified
>> update counts.

> Any guess as to the performance implications?

Pushing some counts from one place to another doesn't seem that
expensive, but it'd be nice to avoid scanning a lot of unrelated
table-stats entries to find the ones that have to be adjusted.
Not sure what it'll take exactly.

Or we could blow it off for the time being. Certainly, getting
things right at the top-transaction level would already be a big
leg up in accuracy from where we are, and I don't think that would
be hard at all.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paolo Ditto 2006-01-28 16:38:37 help
Previous Message Tom Lane 2006-01-28 16:04:09 Re: creating users per database

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-01-29 01:10:58 Re: stats for failed transactions (was Re: [GENERAL] VACUUM
Previous Message Matthew T. O'Connor 2006-01-28 15:53:54 Re: stats for failed transactions (was Re: [GENERAL] VACUUM