"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> Is there a reason why readv/writev have not been considered in the past?
Lack of portability, and lack of obvious usefulness that would justify
dealing with the lack of portability.
I don't think there's any value in trying to write ordinary buffers this
way; making the buffer manager able to write multiple buffers at once
sounds like a great deal of complexity and deadlock risk in return for
not much. It might be an alternative to the existing proposed patch for
writing multiple WAL buffers at once, but frankly I consider that patch
a waste of effort. In real scenarios you seldom get to write more than
one WAL page without a forced sync occurring because someone committed.
Even if *your* transaction is long, any other backend committing a small
transaction still fsyncs. On top of that, the bgwriter will be flushing
WAL in order to maintain the write-ahead rule any time it dumps a dirty
buffer. I have a personal to-do item to make the bgwriter explicitly
responsible for writing completed WAL pages as part of its duties, but
I haven't done anything about it because I think that it will write lots
of such pages without any explicit code, thanks to the bufmgr's LSN
interlock. Even if it doesn't get it done that way, the simplest answer
is to add a little bit of code to make sure bgwriter generally does the
writes, and then we don't care.
If you want to experiment with writev, feel free, but I'll want to see
demonstrable performance benefits before any such code actually goes in.
regards, tom lane