Back-patch "Fix EquivalenceClass processing for nested append relations".
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Jun 2014 17:41:01 +0000 (10:41 -0700)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Jun 2014 17:41:59 +0000 (10:41 -0700)
commita2db7b7d0135c4068ebc3806931e60d5edd8f5cf
treecb836713e94fd9263dc0affc878fee7db8b27234
parent131ec00c0dc45e03aea86728b3645cca51616ada
Back-patch "Fix EquivalenceClass processing for nested append relations".

When we committed a87c729153e372f3731689a7be007bc2b53f1410, we somehow
failed to notice that it didn't merely improve plan quality for expression
indexes; there were very closely related cases that failed outright with
"could not find pathkey item to sort".  The failing cases seem to be those
where the planner was already capable of selecting a MergeAppend plan,
and there was inheritance involved: the lack of appropriate eclass child
members would prevent prepare_sort_from_pathkeys() from succeeding on the
MergeAppend's child plan nodes for inheritance child tables.

Accordingly, back-patch into 9.1 through 9.3, along with an extra
regression test case covering the problem.

Per trouble report from Michael Glaesemann.
src/backend/optimizer/path/allpaths.c
src/backend/optimizer/path/equivclass.c
src/backend/optimizer/plan/createplan.c
src/test/regress/expected/union.out
src/test/regress/sql/union.sql