>
> There is a spot on the disk to which the current WAL is destined to go.
> That spot on the disk is not going to be under the write-head for (say)
> another 6 milliseconds.
>
> Without commit_delay, I try to commit my record, but find that someone else
> is already on the lock (and on the fsync as well). I have to wait for 6
> milliseconds before that person gets their commit done and releases the
> lock, then I can start mine, and have to wait another 8 milliseconds (7500
> rpm disk) for the spot to come around again, for a total of 14 milliseconds
> of latency.
>
> With commit_delay, I get my record in under the nose of the person who is
> already doing the delay, and they wake up and flush it for me in time to
> make the 6 millisecond cutoff. Total 6 milliseconds latency for me.
Right. The example makes it very clear. Thanks for such a detailed explanation.
> One thing I tried a while ago (before the recent group-commit changes were
> made) was to record in shared memory when the last fsync finished, and then
> the next time someone needed to fsync, they would sleep until just before
> the write spot was predicted to be under the write head again
> (previous_finish + rotation_time - safety_margin, where rotation_time -
> safety_margin were represented by a single guc). It worked pretty well on
> the system in which I wrote it, but seemed too brittle to be a general
> solution.
Can we look at researching a general formula for the above? It looks a
bit touchy, but could be made to work. Another option is to add a
probabilistic factor in the formula. Idk, it just seems to be a hunch
I have.
Regards,
Atri
--
Regards,
Atri
l'apprenant
