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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > I'm not clear on what truncate_useless_pathkeys is doing.
>
> It's throwing away pathkey info that isn't relevant for the current
> query (and would cause the planner to consider a multi-column-index
> scan as better-ordered than a scan of an index with fewer columns,
> when no such thing is true if the extra columns aren't relevant).

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.

Having truncate_useless_pathkeys removing the prefix means removing col2 from
the pathkeys leaving col1. In fact once the restriction is taken into account
the ordering of the path is in fact simply col2, which is just what's needed
for the mergejoin.

> > If it were changed to just keep the suffix would that break other things?
>
> Yes, that would be completely backwards.

I'm not clear on how removing the suffix is ever useful. Even in a query like:

SELECT * FROM table_a join table_b using (col1,col2) WHERE a.col1 between $0 and $1

The suffix is still relevant, the merge join is still possible.

--
greg