On 1/27/2006 10:56 AM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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 thou
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 roll
Tom,
I'd argue it's fine: there are tons of people using row-level stats
via autovacuum, and (AFAICT) just about nobody using 'em for any other
purpose. Certainly you never see anyone suggesting them as a tool for
investigating problems on pgsql-performance.
Actually, I use the stats for pe
"Matthew T. O'Connor" 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
Tom Lane wrote:
I'd argue it's fine: there are tons of people using row-level stats
via autovacuum, and (AFAICT) just about nobody using 'em for any other
purpose. Certainly you never see anyone suggesting them as a tool for
investigating problems on pgsql-performance. Sure, it's a repurposing
"Matthew T. O'Connor" writes:
> None of this directly addresses the question of what the stats system
> *should* track, but perhaps it is wrongheaded to totally redesign the
> stats system for the purposes of autovacuum.
I'd argue it's fine: there are tons of people using row-level stats
via au
Tom Lane wrote:
hmm... That's true. I don't think autovacuum doesn't anything to account
for the concept of rolledback inserts.
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
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> My question was at a higher level, actually: *what* should we be
> >> counting?
>
> > Oh, I see. Do you think small incremental improvements to the stat
> > system will buy us much? I think we should be thinkin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My question was at a higher level, actually: *what* should we be
>> counting?
> Oh, I see. Do you think small incremental improvements to the stat
> system will buy us much? I think we should be thinking big here, i.e.
> rewrite mos
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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.
> >>
> >>
Alvaro Herrera <[EMAIL PROTECTED]> 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
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
"Matthew T. O'Connor" writes:
>> Also, somebody made a real good point about rolled-back insertions.
>> Even if the only command you ever apply to the table is INSERT, you
>> could still have dead rows in the table if some of those transactions
>> occasionally roll back.
> hmm... That's true. I
13 matches
Mail list logo
