Alvaro Herrera <alvherre@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
