| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> | 
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David Brown" <time(at)bigpond(dot)net(dot)au> | 
| Cc: | <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: Planner really hates nested loops | 
| Date: | 2005-02-03 16:41:37 | 
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE4767B0@algol.sollentuna.se | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
> > 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)
AFAIK, you can't control what is cached for reading.
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Din Adrian | 2005-02-03 16:59:40 | Re: [PERFORM] Tunning postgresql on linux (fedora core 3) | 
| Previous Message | Tom Lane | 2005-02-03 16:27:38 | Re: GiST indexes and concurrency (tsearch2) |