Hello,
I've been trying to play with support functions for a use-case of ours, and found some behaviors I don't know are expected or not.
The use case: we have some complicated queries, where whole-branches of the execution tree could be cut if some things were evaluated at planning time. Take the following simplified example:
CREATE OR REPLACE FUNCTION myfunction(t1_id int) AS $$
SELECT *
FROM sometable t1
JOIN sometable t2 on t2.t1_id =
t1.idWHERE id = t1_id AND t1.somecolumn IS NOT NULL
$$ language SQL;
If I were to incorporate this function in a larger query, the planner will choose a plan based on a generic value of t1_id and may estimate a large rowcount after inlining.
What I want to do is to evaluate whether id = t1_id AND somecolumn is NOT NULL at planification time, and replace the function by another one if this can be pruned altogether.
So, what I've been doing is to implement a support function for SupportRequestSimplify, and If the predicate doesn't match any row, replace the FuncExpr by a new one, calling a different function.
This seems to work great, but I have several questions:
1) Is it valid to make SPI calls in a support function to do this kind of simplification ?
2) My new FuncExpr doesn't get inlined. This is because in inline_set_returning_function, we check that after the call to eval_const_expressions we still call the same function. I think it would be better to first simplify the function if we can, and only then record the function oid and call the rest of the machinery. I tested that naively by calling eval_const_expressions early in inline_set_returning_function and it seems to do the trick. A proper patch would likely only call the support function at this stage.
What do you think ?
This e-mail message and any attachments to it are intended only for the named recipients and may contain legally privileged and/or confidential information. If you are not one of the intended recipients, do not duplicate or forward this e-mail message.
