Ewe, so we have this 1/200 second delay for every transaction. Seems
bad to me.
I think as long as it becomes a tunable this isn't a bad idea at
all. Fixing it at 1/200 isn't so great because people not wrapping
large amounts of inserts/updates with transaction blocks will
Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync yourself). That would offer less-than-
I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack. You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.
The "buffered log" still guarantees consistency within the
I am just suggesting that instead of flushing the log on every
transaction end, just do it every X seconds.
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Andreas
[ Charset ISO-8859-1 unsupported, converting... ]
I am just suggesting that instead of flushing the log on every
transaction end, just do it every X seconds.
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Log filling is too abritrary. If I
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Log filling is too abritrary. If I commit something, and nothing
happens for 2 hours, we should commit that transaction.
Checkpoint, as I said ?
Andreas
[ Charset ISO-8859-1 unsupported, converting... ]
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Log filling is too abritrary. If I commit something, and nothing
happens for 2 hours, we should commit that transaction.
Checkpoint, as I
