On 10/18/14, 5:16 AM, Tom Lane wrote:
> BTW, on re-reading that code I notice that it will happily seize upon
> the first suitable index ("first" in OID order), regardless of how many
> lower-order columns that index has got. This doesn't make any difference
> I think for get_actual_variable_range's own purposes, because it's only
> expecting to touch the endmost index page regardless. However, in light
> of Marko's complaint maybe we should teach it to check all the indexes
> and prefer the matching one with fewest columns? It would only take a
> couple extra lines of code, and probably not that many added cycles
> considering we're going to do an index access of some sort. But I'm
> not sure if it's worth any extra effort --- I think in his example
> case, there wasn't any narrower index anyway.
Perhaps accidentally this would have helped in my case, actually, since
I could have created a new, smaller index CONCURRENTLY and then seen
that the usage of the other index stopped increasing. With the "pick
the smallest OID" behaviour that was not possible. Another idea had was
some way to tell the optimizer not to use that particular index for
stats lookups, but probably the use case for such a feature would be a
bit narrow.
All that said, I don't think my struggles justify the change you
described above. Not sure if it's a good idea or not.
.marko