Re: index scan with index cond on first column doesn't recognize sort order of second column

Greg Stark <gsstark(at)mit(dot)edu> writes:
> But it might be better ordered. I think you may have missed the original
> context. In a query like:
> SELECT * FROM table_a join table_b using (col2) WHERE a.col1 = $0
> Where there's an index on table_a(col1,col2) could use a merge join without a
> sort.

Yes. The appropriate way to recognize that (without breaking things)
is to consider that the indexscan generates pathkeys (col2) because col1
can be assumed constant. This is not truncate_useless_pathkeys's
business, however. It would have to be done in the code that creates
the indexscan path to begin with. (Ideally, we'd mark the path to show
that it could be considered to have either sort ordering (col1, col2)
or sort ordering (col2), so that it could match to either requirement.
I'm not sure if that's feasible with the current datastructures though.
Might have to make two copies of the path :-()

> I'm not clear on how removing the suffix is ever useful.

It reduces the number of alternatives that add_path will keep track of,
thus making for a combinatorial reduction in the cost of planning.

Actually you are barking up the wrong tree entirely; I'm pretty certain
that truncate_useless_pathkeys *doesn't* remove this pathkey, because it
should notice that it is relevant to the mergejoin condition.

regards, tom lane