Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Has anyone got any thoughts about the best way to do this?
> How about doing both: sort the index by index scan cost; then pick the
> first index on the list and start adding indexes when they lower the
> cost. When adding each index
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think the concern about condition redundancy should be attacked
> separately. How about just comparing whether they have common prefixes
> of conditions? I admit I don't understand what would happen with
> indexes defined like (lower(A), B, C) versus
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Instead of sorting, I suggest the quickselect() algorithm, which is
> O(n).
What for? Common cases have less than half a dozen entries. That is
not the place we need to be spending engineering effort --- what we
need to worry about is what's the choice
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Alvaro Herrera
> Sent: Friday, April 13, 2007 4:24 PM
> To: Tom Lane
> Cc: [EMAIL PROTECTED]; PostgreSQL Performance; Steve
> Subject: Re: [HACKERS] choose_bit
Tom Lane wrote:
> One idea I thought about was to sort by index scan cost, using
> selectivity only as a tiebreaker for cost, rather than the other way
> around as is currently done. This seems fairly plausible because
> indexscans that are cheaper than other indexscans likely return fewer
> rows
Steve <[EMAIL PROTECTED]> writes:
> [ strange planner misbehavior in 8.2.3 ]
After some off-list investigation (thanks, Steve, for letting me poke
at your machine), the short answer is that the heuristics used by
choose_bitmap_and() suck. The problem query is like
select ... from ds where
ds.re
