On Tue, Dec 12, 2023 at 9:55 PM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > By and large, this patch is in a good state and may be committed.
OK, so a few people like the current form of this patch but we haven't heard from Tom since August. Tom, any thoughts on the current incarnation? Richard, I think it could be useful to put a better commit message into the patch file, describing both what problem is being fixed and what the design of the fix is. I gather that the problem is that we crash if the query contains a partioningwise join and also $SOMETHING, and the solution is to move reparameterization to happen at createplan() time but with a precheck that runs during path generation. Presumably, that means this is more than a minimal bug fix, because the bug could be fixed without splitting can-it-be-reparameterized to reparameterize-it in this way. Probably that's a performance optimization, so maybe it's worth clarifying whether that's just an independently good idea or whether it's a part of making the bug fix not regress performance. I think the macro names in path_is_reparameterizable_by_child could be better chosen. CHILD_PATH_IS_REPARAMETERIZABLE doesn't convey that the macro will return from the calling function if not -- it looks like it just returns a Boolean. Maybe REJECT_IF_PATH_NOT_REPARAMETERIZABLE and REJECT_IF_PATH_LIST_NOT_REPARAMETERIZABLE or some such. Another question here is whether we really want to back-patch all of this or whether it might be better to, as Tom proposed previously, back-patch a more minimal fix and leave the more invasive stuff for master. -- Robert Haas EDB: http://www.enterprisedb.com
