I wrote: > Thinking more about this leads me to the following proposal: > 1. Explicitly group the indexes according to the subset of > WHERE-conditions (and partial index conditions, if any) they use. > Within each such group, discard all but the cheapest-scan-cost one.
> 2. Sort the remaining indexes according to scan cost.
> 3. For each index in order, consider it as a standalone scan, and also
> consider adding it on to the AND-group led by each preceding index,
> using the same logic as now: reject using any WHERE-condition twice
> in a group, and then add on only if the total cost of the AND-group
> scan is reduced.
Here is a patch along these lines, in fact two patches (HEAD and 8.2
versions). The 8.2 version picks up some additional partial-index
intelligence that I added to HEAD on Mar 21 but did not at that time
risk back-patching --- since this is a fairly large rewrite of the
routine, keeping the branches in sync seems best.
Steve, can you try this out on your queries and see if it makes better
or worse decisions? It seems to fix your initial complaint but I do
not have a large stock of test cases to try.
regards, tom lane
binVbRvzPiN4t.bin
Description: choose-bitmap-and-head.patch.gz
binnwEWxcSJR4.bin
Description: choose-bitmap-and-82.patch.gz
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
