Re: How does the planner deal with multiple possible indexes? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: How does the planner deal with multiple possible indexes?
Date
Msg-id 17149.1153353289@sss.pgh.pa.us
Whole thread Raw
In response to Re: How does the planner deal with multiple possible indexes?  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: How does the planner deal with multiple possible indexes?  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Indeed, if I find a case where there's a large enough number of rows it
> will choose the smaller index. But I'm wondering if it would be better
> to always favor the smaller index, since it would (presumably) be easier
> to keep it in cache?

AFAICS, in existing releases that should happen, because the cost
estimate varies with the size of the index.  And it does happen for me
in simple tests.  You did not provide the requested information to help
us find out why it's not happening for you.

(I'm a bit worried about whether CVS HEAD may have broken this behavior
with the recent changes in the indexscan cost equations ... but unless
you are working with HEAD that's not relevant.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Freezing tuples on pages dirtied by vacuum
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Resurrecting per-page cleaner for btree