Re: Optimze usage of immutable functions as relation - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Optimze usage of immutable functions as relation
Date
Msg-id 87zi1g6jbj.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Optimze usage of immutable functions as relation  (Aleksandr Parfenov <a.parfenov@postgrespro.ru>)
Responses Re: Optimze usage of immutable functions as relation  (Aleksandr Parfenov <a.parfenov@postgrespro.ru>)
List pgsql-hackers
>>>>> "Aleksandr" == Aleksandr Parfenov <a.parfenov@postgrespro.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)


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?
Next
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)