Magnus wrote:
> > > I'm hoping someone can shed some light on these results.
> >
> > Not without a lot more detail on how you *got* the results.
> > What exactly did you do to force the various plan choices?
> > (I see some ridiculous choices of indexscans, for instance,
> > suggesting improper use of enable_seqscan in some cases.)
> > And what's the "cache rows" and "disk rows" stuff, and how do
> > you know that what you were measuring is actually what you
> > think it is? I have zero confidence in Windows-atop-ATA as a
> > platform for measuring disk-related behaviors, because I
> > don't think you can control or even know what caching is going on.
>
> You can control the writeback-cache from Device Manager->(the
> disk)->Policies. And if that is turned off, fsync definitly should
write
> through, just as on *nix. (write-cache is on by default, no surprise)
There is some truth to what Tom is saying, we just can't seem to get our
development server to *quit* syncing with fsync=on, even though we have
the Promise raid controller (yeah, I know) configured to cache writes.
IOW, with certain configurations I just can't seem to delegate sync
responsibility to the raid controller. It is a matter of record that
certain crappy drives lie about caching but, IMO this is more of a
driver issue than a O/S issue. (aside: I have become quite a believer
in Western Digital parts, lately!)
Merlin