> No question about that! The sooner we can get stuff to the WAL buffers,
> the more likely we will get some other transaction to do our fsync work.
> Any ideas on how we can do that?
More like the sooner we get stuff out of the WAL buffers and into the
disk's buffers whether by write or aio_write.
It doesn't do any good to have information in the XLog unless it
gets written to the disk buffers before they empty.
> We hesitate to add code relying on new features unless it is a
> significant win, and in the aio case, we would have different WAL disk
> write models for with/without aio, so it clearly could be two code
> paths, and with two code paths, we can't as easily improve or optimize.
> If we get 2% boost out of some feature, but it later discourages us
> from adding a 5% optimization, it is a loss. And, in most cases, the 2%
> optimization is for a few platform, while the 5% optimization is for
> all. This code is +15 years old, so we are looking way down the road,
> not just for today's hot feature.
I'll just have to implement it and see if it's as easy and isolated as I
think it might be and would allow the same algorithm for aio_write or
write.
> I can't tell you how many aio/mmap/fancy feature discussions we have
> had, and we obviously discuss them, but in the end, they end up being of
> questionable value for the risk/complexity; but, we keep talking,
> hoping we are wrong or some good ideas come out of it.
I'm all in favor of keeping clean designs. I'm very pleased with how
easy PostreSQL is to read and understand given how much it does.
- Curtis
