Thanks for your prompt reply.
On Thu, 2003-09-18 at 16:19, Matt Clark wrote:
> > We thought the large effective_cache_size should lead us to better
> > plans. But we found the opposite.
>
> Maybe it's inappropriate for little old me to jump in here, but the plan
> isn't usually that important compared to the actual runtime. The links you
> give show the output of 'explain' but not 'explain analyze', so it's not
> clear wich plan is actually _faster_.
>
I put the EXPLAIN ANALYZE output at:
http://developer.osdl.org/~jenny/large_explain_analyze
http://developer.osdl.org/~jenny/small_explain_analyze
The actual execution time is 37 seconds(large) vs 5 seconds (small).
I concluded the one with nested loop one is faster since we saw it
consistently faster than the merge join one in our runs.
> If you really do have only 8MB of FS cache, then either plan will run
> slowly. If you really do have 5GB of FS cache then either plan will run a
> lot faster. Why would you deliberately give the planner false information
> about this?
>
We did not. A little history of our runs:
When we first started, not knowing PG well, we just used the default ECS
value(1000).
Then we realized since we have 8G of RAM, we should set ECS to 655360.
But this leads the optimizer to pick a bad plan. This is the reason why
we post this message.
> PG obviously thinks plan 1 is 'better' when pages have to be fetched from
> disk, and plan 2 is 'better' when they don't. Which is really better
> depends on whether those pages do have to be fetched from disk or not, and
> PG can only know what you tell it about that, so changing ECS without
> actually removing the RAM from the system seems a little pointless to me...
>
> M
>
>
>
Regards,
Jenny
