"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano@mailbox.hu> writes:
> Last week I fumbled with CPU_TUPLE_COST and revealed that 4 out of 4 tested
> queries improved by 10-60% if I changed it from 0.01 (default) to 0.40
> (ugh). Setting it higher did not bring any improvement.
That's pretty hard to believe; particularly on modern machines, I'd
think that moving it down would make more sense than moving it up.
You're essentially asserting that the CPU time to process one tuple
is almost half of the time needed to bring a page in from disk.
I suspect that your test cases were toy cases small enough to be
fully cached and thus not incur any actual I/O ...
> [ trying to get a nestloop indexscan plan to be generated ]
I believe that the planner's cost model for nestloops with inner
indexscan is wrong: it costs each inner iteration independently, when
in fact there should be some savings, because at least the topmost
levels of the index will soon be fully cached. However, when I tried
to work out a proper model of this effect, I ended up with equations
that gave higher indexscan costs than what's in there now :-(. So that
didn't seem like it would make anyone happy.
regards, tom lane
