Re: slow commits with heavy temp table usage in 8.4.0

Tom Lane wrote:
> 
> Actually, this is easier than I thought, because there is already
> bookkeeping being done that (in effect) tracks whether a table has
> already been truncated in the current transaction.  So we can rely
> on that, and with only a very few lines of code added, ensure that
> a situation like this does only one full-scale transaction-safe
> truncation per transaction.  The attached prototype patch does this
> and seems to fix the speed problem nicely.  It's not tremendously
> well tested, but perhaps you'd like to test?  Should work in 8.4.

I downloaded the 8.4 source, built it unmodified, created a new cluster,
and ran the test in an empty DB there.  Function execution took about
230 seconds, and commit took about 6 seconds.

With the patch applied, the test only took 35 seconds, and the commit
was practically instant (30ms).  I monitored the database directory,
and the test execution only created 2 files (down from 60000).

Thanks for the patch; it looks great. :)

Is there any chance that it will be backpatched to 8.4?

-- todd