> I also encountered the similar performance issue with temporary tables > andprovided a patch to optimize the truncate performance during commit > in [1].
Interesting, that is definitely another good way to improve the performance, especially with a large number of temp tables. I think the two optimizations can actually work well together. Your optimization on only truncating the tables that are actually used. Combined with a patch like attached which makes sure that no WAL is generated at all for the ON COMMIT DELETE ROWS operation. On my test system this reduces WAL generation for the pgbench test case I posted previously to 0 (and therefore brought WAL replay process CPU usage from 100% CPU and lagging behind to only 0% CPU usage) -Floris
0001-Remove-any-WAL-logging-for-ON-COMMIT-DELETE-ROWS.patch
Description: 0001-Remove-any-WAL-logging-for-ON-COMMIT-DELETE-ROWS.patch
