> 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