Tom Lane wrote:
> One additional point: this means that one transaction in every 32K
> writing transactions *does* have to do extra work when it assigns itself
> an XID, namely create and zero out the next page of pg_clog. And that
> doesn't just slow down the transaction in question, but the next few
> guys that would like an XID but arrive on the scene while the
> zeroing-out is still in progress.
>
> This probably contributes to the behavior that Simon and Josh regularly
> complain about, that our transaction execution time is subject to
> unpredictable spikes. I'm not sure how to get rid of it though.
A thread maintaining a pool of assigned and cleared pg_clog pages, ahead
of the immediate need? Possibly another job for an existing daemon
thread.
- Jeremy