"Bossart, Nathan" <bossartn@amazon.com> writes: > I periodically hear rumblings about this behavior as well. At the > very least, it certainly ought to be documented if it isn't yet. I > wouldn't mind trying my hand at that. Perhaps we could also add a new > configuration parameter if users really want to take the performance > hit.
A sequence's cache length is already configurable, no?
We can hit this issue even cache=1. And even if we added the XLogFlush,
with _cachesize=1_, the Xlog is still recorded/flushed every 32 values.
I know your opinion about this at [1], IIUC you probably miss the SEQ_LOG_VALS
design, it was designed for the performance reason to avoid frequent xlog updates already.
But after that, the XLogSync is still not called which caused this issue.
