It does the trick by tracking if a TRUNCATE command was issued under a (sub)transaction and uses this knowledge to reset the live/dead tuple counters later if the transaction was committed. Testing in simple cases shows that this clears the counters correctly, including use of savepoints. The 2PC part requires extending bool flag to fit the trunc flag, is this approach sane? Given that 2PC transaction should survive server restart, it's reasonable to expect it to also survive the upgrade, so I see no clean way of adding another bool field to the TwoPhasePgStatRecord struct (unless some would like to add checks on record length, etc.). I'm going to add some regression tests, but not sure what would be the best location for this. The truncate.sql seems like natural choice, but stats are not updating realtime, so I'd need to borrow some tricks from stats.sql or better put the new tests in the stats.sql itself? -- Regards, Alex > --------------------------------------------------------------------------- > > Tom Lane wrote: >> Alvaro Herrera writes: >> > Tom Lane wrote: >> >> Just noticed that TRUNCATE fails to clear the stats collector's counts >> >> for the table. I am not sure if it should reset the event counts or >> >> not (any thoughts?) but surely it is wrong to not zero the live/dead >> >> tuple counts. >> >> > Agreed, the live/dead counters should be reset. Regarding event counts, >> > my take is that we should have a separate statement count for truncate >> > (obviously not a tuple count), and the others should be left alone. >> >> I thought some more about how to do it, and stumbled over how to cope >> with TRUNCATE being rolled back. That nixed my first idea of just >> having TRUNCATE send a zero-the-counters-now message. >> >> regards, tom lane