Aleksandr Parfenov <asp...@gmail.com> writes: > [ funcscan_plan_optimizer_v4.patch ]
A small note here --- this would be noticeably cleaner if removal of the no-longer-needed function RTE were done using the dummy-relation infrastructure I proposed in https://commitfest.postgresql.org/20/1827/ Maybe we should get that done first and then come back to this. I'm a bit suspicious of the premise of this though, because it's going to result in a single call of a function being converted into possibly many calls, if the RTE is referenced in a lot of places. Even if the function is immutable so that those calls get evaluated at plan time not run time, it's still N calls not one, which'd be bad if the function is expensive. See e.g. https://www.postgresql.org/message-id/flat/CAOYf6edujEOGB-9fGG_V9PGQ5O9yoyWmTnE9RyBYTGw%2BDq3SpA%40mail.gmail.com for an example where we're specifically telling people that they can put a function into FROM to avoid multiple evaluation. This patch breaks that guarantee. A possible fix for this is to do eval_const_expressions() on function RTE expressions at this stage (and then not need to do it later), and then pull up only when we find that the RTE expression has been reduced to a single Const. I'm not sure whether invoking eval_const_expressions() so early would create any issues. But if it can be made to work, this would eliminate quite a lot of the ad-hoc conditions that you have in the patch now. regards, tom lane