When costing a btree index scan, num_sa_scans gets computed twice, once in btcostestmeate and once in genericcostestimate. But the computations are different. It looks like the generic one includes all =ANY in any column in the index, while the bt one includes only =ANY which or on columns for which all the preceding index columns are tested for equality.
It looks like the generic one was there first then the bt-specific one was added later to improve planning of btree indexes. But then shouldn't the value be passed down to generic, rather than recomputed (differently)? I've attached a patch to do that. Generic still computes the value itself for other-than-btree indexes. Or, is there a reason we want a different value to be used in genericcostestimate? The context for this is that I was looking at cases where btree indexes were not using all the columns they could, but rather shoving some of the conditions down into a Filter unnecessarily/unhelpfully. This change doesn't fix that, but it does seem to be moving in the right direction. This does cause a regression test failure due to an (apparently?) uninteresting plan change. Cheers, Jeff
eq_any.patch
Description: Binary data
