On Sun, Nov 08, 2020 at 06:19:57PM -0500, Greg Stark wrote:
> However in the case of ON COMMIT DELETE ROWS we can do better. Why not
> just reset the relfrozenxid and other stats as if the table was
> freshly created when it's truncated?
That concept is sound.
> 1) Should we update relpages and reltuples. I think so but an argument
> could be made that people might be depending on running analyze once
> when the data is loaded and then not having to run analyze on every
> data load.
I'd wager no, we should not. An app that ever analyzes an ON COMMIT DELETE
ROWS temp table probably analyzes it every time. If not, it's fair to guess
that similar statistics recur in each xact.
> 2) adding the dependency on heapam.h to heap.c makes sense because of
> heap_inplace_update bt it may be a bit annoying because I suspect
> that's a useful sanity check that the tableam stuff hasn't been
> bypassed
That is not terrible. How plausible would it be to call vac_update_relstats()
for this, instead of reimplementing part of it?
> 3) I added a check to the regression tests but I'm not sure it's a
> good idea to actually commit this. It could fail if there's a parallel
> transaction going on and even moving the test to the serial schedule
> might not guarantee that never happens due to autovacuum running
> analyze?
Right.
> @@ -3340,6 +3383,7 @@ heap_truncate_one_rel(Relation rel)
>
> /* Truncate the underlying relation */
> table_relation_nontransactional_truncate(rel);
> + ResetVacStats(rel);
I didn't test, but I expect this will cause a stats reset for the second
TRUNCATE here:
CREATE TABLE t ();
...
BEGIN;
TRUNCATE t;
TRUNCATE t; -- inplace relfrozenxid reset
ROLLBACK; -- inplace reset survives
Does that indeed happen?