Re: Planner really hates nested loops
От | Merlin Moncure |
---|---|
Тема | Re: Planner really hates nested loops |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A760E@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | Planner really hates nested loops (David Brown <time@bigpond.net.au>) |
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: