-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_bitmap_and again (was Re: [PERFORM
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
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 (A,
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,
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
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
