At a high level, I'm a bit disturbed that this focuses only on DISTINCT and doesn't (appear to) have any equivalent intelligence for GROUP BY, though surely that offers much the same opportunities for optimization. It seems like it'd be worthwhile to take a couple steps back and see if we couldn't recast the logic to work for both.
OK, Looks group by is a bit harder than distinct since the aggregation function.
I will go through the code to see why to add this logic.
Can we grantee any_aggr_func(a) == a if only 1 row returned, if so, we can do
some work on the pathtarget/reltarget by transforming the Aggref to raw expr.
I checked the execution path of the aggregation call, looks it depends on Agg node
which is the thing we want to remove.
* There seem to be some pointless #include additions, eg in planner.c the added code doesn't look to justify any of them. Please also avoid unnecessary whitespace changes, those also slow down reviewing.
fixed some typo errors.
That may be because I added the header file at time 1 and then refactored
the code but forget to remove the header file when it is not necessary.
Do we need to relay on experience to tell if the header file is needed or not,