Jeff Janes writes:
> Why does having the =ANY in the "Index Cond:" rather than the "Filter:"
> inhibit it from understanding that the rows will still be delivered in
> order by "thousand"?
They won't be. The =ANY in index conditions results in multiple
index scans, that is we effectively do a sc
Jeff Janes writes:
> 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 =AN
On Sun, Aug 21, 2022 at 2:45 PM Jeff Janes wrote:
> ...
>
> 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
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
wh
