Philip Warner <pjw@rhyme.com.au> writes:
> Again. this is OK, although I am a little surprised at the continuing
> non-linearity of the estimates.
Indexscan estimates are supposed to be nonlinear, actually, to account
for the effects of caching. I doubt the shapes of the curves are right
in detail, but I haven't had time to do any research about it.
> I would be interested to know (a) if there is any way I can influence the
> optimizer choice when it considers using the index in question,
You could push random_page_cost and effective_cache_size around to try
to match your platform better. Let me know if that helps...
> (b) if the fixed seqscan cost estimate is a bug.
I don't think so. A seqscan will touch every page and every tuple once,
therefore the costs should be pretty much independent of the number of
tuples that actually get selected, no? (Note that the time spent
returning tuples to the frontend is deliberately ignored by the
optimizer, on the grounds that every correct plan for a given query
will have the exact same output costs. So if you want to try to compare
the planner's cost estimates to real elapsed time, you might want to
measure the results for "select count(*) from ..." instead of "select *
from ..." so that output costs are held fixed.)
regards, tom lane
