Re: [HACKERS] Partition-wise aggregation/grouping

 > Regarding apply_scanjoin_target_to_paths in 0001 and 0007, it seems
 > like what happens is: we first build an Append path for the topmost
 > scan/join rel.  That uses paths from the individual relations that
 > don't necessarily produce the final scan/join target.  Then we mutate
 > those relations in place during partition-wise aggregate so that they
 > now do produce the final scan/join target and generate some more paths
 > using the results.  So there's an ordering dependency, and the same
 > pathlist represents different things at different times.  That is, I
 > suppose, not technically any worse than what we're doing for the
 > scan/join rel's pathlist in general, but here there's the additional
 > complexity that the paths get used both before and after being
 > mutated.  The UPPERREL_TLIST proposal would clean this up, although I
 > realize that has unresolved issues.

I discouraged by this logic.
Now I use set_rel_pathlist_hook and make some optimizations at partition 
scanning paths. But apply_scanjoin_target_to_paths() deletes pathlist 
and violates all optimizations.
May be it is possible to introduce some flag, that hook can set to 
prevent pathlist cleaning?

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company