Fwiw, what made you bring up this topic now? You're the second person in about two days to bring up precisely this issue and it was an issue I had been planning to bring up on -hackers as it was. "Matthew" <matthew@xxxxxxxxxxx> writes: > Kind of. The system cache is just a method to make it simpler to explain - > I don't know the operating system interfaces, but it's likely that the > actual call is something more like "transfer these blocks to these memory > locations and tell me when they're all finished." I'm trying to make a > single query concurrent by using the knowledge of a *list* of accesses to > be made, and getting the operating system to do all of them concurrently. There are two interfaces of which I'm aware of. posix_fadvise() which just tells the kernel you'll be needing the blocks soon. Linux at least initiates I/O on them into cache. libaio which lets you specify the location to read the blocks and how to notify you when they're ready. On Linux posix_fadvise works great but libaio doesn't seem to gain any speed bonus, at least on 2.6.22 with glibc 2.6.1. I was under the impression there was a kernel implementation somewhere but apparently it's not helping. On Solaris apparently it doesn't have posix_fadvise but libaio works great. We could use libaio as a kind of backdoor fadvise where we just initiate i/o on the block but throw away the results assuming they'll stay in cache for the real read or we could add an asynchronous interface to the buffer manager. The latter is attractive but would be a much more invasive patch. I'm inclined to start with the former. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
