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