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? > To the point of making a dedicated pgstat testing tool: let's have > another TODO item? Sure. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
