SupportRequestSimplify and SQL SRF

From: Ronan Dunklau <ronan_dunklau(at)ultimatesoftware(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: SupportRequestSimplify and SQL SRF
Date: 2020-03-18 09:39:10
Message-ID: CAA8M49qJajiQMr2giF0T=3sbL+bmxK+3deUgtm0tq4yMQX921A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.id
WHERE 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-03-18 09:59:51 Re: RecoveryWalAll and RecoveryWalStream wait events
Previous Message Fujii Masao 2020-03-18 09:31:08 Re: add types to index storage params on doc