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