> 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
