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
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
Matthew T. O'Connor matthew@zeut.net 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
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 matthew@zeut.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
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
Matthew T. O'Connor matthew@zeut.net 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
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
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 to work?
I
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 thoughts about how
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 most stuff
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 thinking big here,
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
13 matches
Mail list logo
