Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Alex Shulgin wrote: > >> OK, I think I have now all bases covered, though the updated patch is >> not that "pretty". >> >> The problem is that we don't know in advance if the (sub)transaction is >> going to succeed or abort, and in case of aborted truncate we need to >> use the stats gathered prior to truncate. Thus the need to track >> insert/update/deletes that happened before first truncate separately. > > Ugh, this is messy indeed. I grant that TRUNCATE is a tricky case to > handle correctly, so some complexity is expected. Can you please > explain in detail how this works?
The main idea is that aborted transaction can leave dead tuples behind (that is every insert and update), but when TRUNCATE is issued we need to reset insert/update/delete counters to 0: otherwise we won't get accurate live and dead counts at commit time. If the transaction that issued TRUNCATE is instead aborted, the insert/update counters that we were incrementing *after* truncate are not relevant to accurate calculation of dead tuples in the original relfilenode we are now back to due to abort. We need the insert/updates counts that happened *before* the first TRUNCATE, hence the need for separate counters. >> To the point of making a dedicated pgstat testing tool: let's have >> another TODO item? > > Sure. Added one. -- Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers