Robert Haas <robertmhaas@gmail.com> writes:
> ...what makes the pathkeys potentially useful is that they match the
> root pathkeys for the query. However, without Greg's hacks, the
> transposed child equivalence classes don't show up in the equivalence
> member lists, so get_eclass_for_sort_expr() generates new equivalence
> classes for them. Subsequently, when truncate_useless_pathkeys() is
> called, those new equivalence classes are found not to be equal to the
> overall ordering desired for the query, so it truncates them away.
> I'm not presently sure quite what the best way to fix this is... any ideas?
Probably what's needed is to extend the "child eclass member" stuff to
cover sort-key eclasses. Per relation.h:
* em_is_child signifies that this element was built by transposing a member* for an inheritance parent relation to
representthe corresponding expression* on an inheritance child. The element should be ignored for all purposes* except
constructinginner-indexscan paths for the child relation.
Likely these need to be ignored a bit less. A couple of Greg's
undocumented hacks seem to be related to this point, but not all of
them. In any case you'd need some careful thought about when to
ignore child EMs and when not.
regards, tom lane