I had a deeper look into $subject. As Tom already noted in [1], this can't
be done by simply issueing a reset message to the stats collector. TRUNCATE
is transactional and can be rolled back. This is becoming more problematic,
if someone is using SAVEPOINTs or is going to fill a previously truncated
table with new data, does some batch jobs on it and commit the transaction.
In this case we want to have accurate live and dead tuple counters, i think.
After looking into the stats code (don't beat me, it's my first time
looking at that code), i think we can achieve a solution by handling a
truncate counter much the same like we do with tuples_inserted and
tuples_deleted.
We maintain a truncate counter and save it's transactional state within the
stats xact structures. This gives us the possiblity to take back any
incremented truncate stats when a transaction is aborted. Within the xact
(or subxact) state of a backend counter we reset it's live and dead tuples
to zero, as soon as we are going to increment the truncate counter. Any
subsequent action on the table will adjust them again.
On the stats collector side, we could distinguish between tabstat messages
with a truncate counter set to zero (no TRUNCATEs at all) or set to any
positive value then. A positive truncate counter will lead to reinitialize
the live and dead tuple statistics to the last values set within the
tabstat message, otherwise we increment live and dead tuple statistics (as
we do now).
One thing that's still unclear to me is wether we want to reset n_tup_ins
and friends accordingly. I don't think that's a good idea, since this
steals the possibility to track down heavily used tables from the DBA (and
what about autovacuum?)
[1] <http://archives.postgresql.org//pgsql-hackers/2008-04/msg00240.php>
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
