Thread: ToDo: Clear table counters on TRUNCATE

ToDo: Clear table counters on TRUNCATE

From
Bernd Helmle
Date:
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