Re: Optimze usage of immutable functions as relation

>>>>> "Aleksandr" == Aleksandr Parfenov <a(dot)parfenov(at)postgrespro(dot)ru> writes:

Aleksandr> The idea of the fix for this situation is to check is a
Aleksandr> result of the function constant or not during the planning
Aleksandr> of the query. Attached patch does this by processing Var
Aleksandr> entries at planner stage and replace them with constant
Aleksandr> value if it is possible. Plans after applying a patch
Aleksandr> (SeqScan query for comparison):

From an implementation point of view your patch is obviously broken in
many ways (starting with not checking varattno anywhere, and not
actually checking anywhere if the expression is volatile).

But more importantly the plans that you showed seem _worse_ in that
you've created extra calls to to_tsquery even though the query has been
written to try and avoid that.

I think you need to take a step back and explain more precisely what you
think you're trying to do and what the benefit (and cost) is.

Specific coding style points (not exhaustive):

Aleksandr> pointedNode->functions->length == 1

list_length()

Aleksandr> pointedNode->functions->head->data.ptr_value

linitial() or linitial_node()

Aleksandr> if (result->type == T_FuncExpr)

IsA()

(what if the result is the inline expansion of a volatile function?)

Aleksandr> pfree(result);

result is a whole tree of nodes, pfree is pointless here

(don't bother trying to fix the above points in this patch, that won't
address the fundamental flaws)

--
Andrew (irc:RhodiumToad)