Re: Stats collector performance improvement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Stats collector performance improvement
Date
Msg-id 12503.1136238525@sss.pgh.pa.us
Whole thread Raw
In response to Re: Stats collector performance improvement  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Responses Re: Stats collector performance improvement  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> AFAICS if we can maintain the stats counts solid, then it may hurt 
> performance dramatically. Think if we maintain 
> pgstat_count_heap_insert()/pgstat_count_heap_delete() pretty well, then we 
> get a replacement of count(*).

Not at all.  For one thing, the stats don't attempt to maintain
per-transaction state, so they don't have the MVCC issues of count(*).
I'm not suggesting any fundamental changes in what is counted or when.

The two compromises that were made in the original stats design to make
it fast were (1) stats updates lag behind reality, and (2) some updates
may be missed entirely.  Now that we have a couple of years' field
experience with the code, it seems that (1) is acceptable for real usage
but (2) not so much.  And it's not even clear that we are buying any
performance gain from (2), considering that it's adding the overhead of
passing the data through an extra process.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Stats collector performance improvement
Next
From: "Andrew Dunstan"
Date:
Subject: Re: psql & readline & win32