(Go back to -hackers) Simon Riggs <[EMAIL PROTECTED]> wrote:
> No action on this seen since last commitfest, but I think we should do > something with it, rather than just ignore it. I will have a plan to test it on RAID-5 disks, where sequential writing are much better than random writing. I'll send the result as an evidence. Also, I have a relevant idea to sorting writes. Smoothed checkpoint in 8.3 spreads write(), but calls fsync() at once. With sorted writes, we can call fsync() segment-by-segment for each writes of dirty pages contained in the segment. It could improve worst response time during checkpoints. > Note that if we do this for checkpoint we should also do this for > FlushRelationBuffers(), used during heap_sync(), for exactly the same > reasons. Ah, I overlooked FlushRelationBuffers(). It is worth sorting. > Would suggest calling it bulk_io_hook() or similar. I think we need to reconsider the "bufmgr - smgr - md" layers, not only an I/O elevator hook. If we will have spreading fsync(), bufmgr should know where the file segments are switched. It seems to break area between bufmgr and md in the current architecture unhappily. In addition, the current smgr layer is completely useless because it cannot be extended dynamically and cannot handle multiple md-layer modules. I would rather merge current smgr and part of bufmgr into a new smgr and add smgr_hook() than bulk_io_hook(). Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers