>
> Yep. To take a degenerate case, suppose that you had many small WAL
> records, say 64 bytes each, so more than 100 per 8K block. If you
> flush those one by one, you're going to rewrite that block 100 times.
> If you flush them all at once, you write that block once.
>
> But even when the range is more than the minimum write size (8K for
> WAL), there are still wins. Writing 16K or 24K or 32K submitted as a
> single request can likely be done in a single revolution of the disk
> head. But if you write 8K and wait until it's done, and then write
> another 8K and wait until that's done, the second request may not
> arrive until after the disk head has passed the position where the
> second block needs to go. Now you have to wait for the drive to spin
> back around to the right position.
>
> The details of course vary with the hardware in use, but there are
> very few I/O operations where batching smaller requests into larger
> chunks doesn't help to some degree. Of course, the optimal transfer
> size does vary considerably based on the type of I/O and the specific
> hardware in use.
This makes a lot of sense. I was always under the impression that
batching small requests into larger requests bears the overhead of I/O
latency. But, it seems to be the other way round, which I have now
understood.
Thanks a ton,
Regards,
Atri
--
Regards,
Atri
l'apprenant