> But it also looks forgotten. Bringing it back to life would mean > building the latest kernel with that patch included, replicating the > benchmarks I ran here, sans pg patch, but with patched kernel, and > reporting the (hopefully equally dramatic) performance improvements in > the kernel ML. That would take me quite some time (not used to playing > with kernels, though it wouldn't be my first time either), though it > might be worth the effort.
Well, informing linux hackers may help. > > I don't know how others (BSD, windows, ...) handle this case. > > I don't even think windows supports posix_fadvise, but if async_io is > used (as hinted by the link Lumby posted), it would probably also work > in windows. > > BSD probably supports it the same way linux does. I though of the opposite way: how do other kernels handle the backwards prefetch. > > > Maybe the strategy to use our own prefetch is better, then I would like > > to use it also in places where we used to hack to make linux understand > > that we will benefits from prefetching. > > It would at least benefit those installations without the > latest-in-the-future kernel-with-backwards-readahead. We're speaking of PostgreSQL 9.3, running cutting edge PostgreSQL and old kernel in end 2013... Maybe it won't be so latest-in-the-future at this time. Btw the improvements you are doing looks good, I just add some information regarding what is achieved around us. > > To which places are you referring to, btw? Maintenance tasks. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
