Make setrefs.c match by ressortgroupref even for plain Vars.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Oct 2017 16:17:40 +0000 (12:17 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Oct 2017 16:17:40 +0000 (12:17 -0400)
commit6a81ba1d4d26b46636d652a3a56143c159da899c
treeb35a8f4777775cd92f7e27f5de84ed662c40e5f5
parenta9d4625f485abd458f8fcc263f0003235430401e
Make setrefs.c match by ressortgroupref even for plain Vars.

Previously, we skipped using search_indexed_tlist_for_sortgroupref()
if the tlist expression being sought in the child plan node was merely
a Var.  This is purely an optimization, based on the theory that
search_indexed_tlist_for_var() is faster, and one copy of a Var should
be as good as another.  However, the GROUPING SETS patch broke the
latter assumption: grouping columns containing the "same" Var can
sometimes have different outputs, as shown in the test case added here.
So do it the hard way whenever a ressortgroupref marking exists.

(If this seems like a bottleneck, we could imagine building a tlist index
data structure for ressortgroupref values, as we do for Vars.  But I'll
let that idea go until there's some evidence it's worthwhile.)

Back-patch to 9.6.  The problem also exists in 9.5 where GROUPING SETS
came in, but this patch is insufficient to resolve the problem in 9.5:
there is some obscure dependency on the upper-planner-pathification
work that happened in 9.6.  Given that this is such a weird corner case,
and no end users have complained about it, it doesn't seem worth the work
to develop a fix for 9.5.

Patch by me, per a report from Heikki Linnakangas.  (This does not fix
Heikki's original complaint, just the follow-on one.)

Discussion: https://postgr.es/m/aefc657e-edb2-64d5-6df1-a0828f6e9104@iki.fi
src/backend/optimizer/plan/setrefs.c
src/test/regress/expected/groupingsets.out
src/test/regress/sql/groupingsets.sql