On Mon, Feb 8, 2010 at 9:49 AM, Josh Berkus <josh@xxxxxxxxxxxx> wrote: > >> That's basically what I've been trying to make clear all along: people >> should keep an open mind, watch what happens, and not make any >> assumptions. There's no clear cut preference for one scheduler or the >> other in all situations. I've seen CFQ do much better, you and Albe >> report situations where the opposite is true. I was just happy to see >> another report of someone running into the same sort of issue I've been >> seeing, because I didn't have very much data to offer about why the >> standard advice of "always use deadline for a database app" might not >> apply to everyone. > > Damn, you would have to make things complicated, eh? > > FWIW, back when deadline was first introduced Mark Wong did some tests > and found Deadline to be the fastest of 4 on DBT2 ... but only by about > 5%. If the read vs. checkpoint analysis is correct, what was happening > is the penalty for checkpoints on deadline was almost wiping out the > advantage for reads, but not quite. > > Those tests were also done on attached storage. > > So, what this suggests is: > reads: deadline > CFQ > writes: CFQ > deadline > attached storage: deadline > CFQ > > Man, we'd need a lot of testing to settle this. I guess that's why > Linux gives us the choice of 4 ... I wonder what the impact is from the underlying RAID configuration. Those DBT2 tests were also LVM striped volumes on top of single RAID0 LUNS (no jbod option). Regards. Mark -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
