* Greg Stark <[EMAIL PROTECTED]> [081024 10:48]: > I thought about how to support both and ran into probblems that would > make the resulting solutions quite complex. > > In the libaio view of the world you initiate io and either get a > callback or call another syscall to test if it's complete. Either > approach has problems for postgres. If the process that initiated io > is in the middle of a long query it might takr a long time ot even > never get back to complete the io. The callbacks use threads... > > And polling for completion has the problem that another process could > be waiting on the io and can't issue a read as long as the first > process has the buffer locked and io in progress. I think aio makes a > lot more sense if you're using threads so you can start a thread to > wait for the io to complete. > > Actually I think it might be doable with a lot of work but I'm worried > that it would be a lot of extra complexity even when you're not using > it. The current patch doesn't change anything when you're not using it > and actually is quite simple.
In the Solaris async IO, are you bound by direct IO? Does the OS page-cache still get primed by async reads? If so, how about starting async IO into a "throwaway" local buffer; treat async IO in the same way as fadvise, a "pre-load the OS page cache so the real read is quick". Sure, I understand it's not the "perfect model", but it I don't see PostgreSQL being refactored enough to have a pure async model happening any time in the near future... -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
