I wrote:
> HarmeekSingh Bedi <harmeeksingh@gmail.com> writes:
>> I did make a fix at least to alleviate this case in the optimizer . But I am
>> going to work on a more general approach of expression pruning based on the
>> lifetime of an expression. Basically each node will either references or
>> generate an expression. Any expression that is generated and is not
>> referenced by any top on top will be eliminated.
> Sounds like overkill.
BTW, I looked a little more closely at the example you posted earlier,
and it's a lot simpler than I initially thought. The actual issue seems
to not be anything to do with placeholders; it's just that
make_subplanTargetList() is lazy about deciding what to put into the
targetlist that will be passed to query_planner. Per its comment,
* For example, given a query like* SELECT a+b,SUM(c+d) FROM table GROUP BY a+b;* we want to pass this targetlist
tothe subplan:* a,b,c,d,a+b* where the a+b target will be used by the Sort/Group steps, and the* other targets
willbe used for computing the final results. (In the* above example we could theoretically suppress the a and b
targetsand* pass down only c,d,a+b, but it's not really worth the trouble to* eliminate simple var references from the
subplan. We will avoid doing* the extra computation to recompute a+b at the outer level; see* fix_upper_expr() in
setrefs.c.)
The extra variables you're complaining about are all used in GROUP BY
expressions, so the above describes exactly the behavior you're seeing.
Possibly it wouldn't be too hard to separate the GROUP BY targetlist
items from the rest and only apply flatten_tlist to the items that
aren't GROUP BY targets. I'm unconvinced that the use case is wide
enough to be worth the trouble, though.
regards, tom lane