Re: Optimze usage of immutable functions as relation

rmrodrig...@carto.com writes: > This commit is breaking some Postgis tests with custom types. Hm, yeah, the code fails to consider the possibility that the function returns a composite type. For the moment I'm just going to make it punt if the function result class isn't TYPEFUNC_SCALAR. In

Re: Optimze usage of immutable functions as relation

Hi, This commit is breaking some Postgis tests with custom types. Here is a minimal repro (Postgis not required) ``` -- test custom types create type t_custom_type AS ( valid bool, reason varchar, location varchar ); create or replace function f_immutable_custom_type(i integer) returns

Re: Optimze usage of immutable functions as relation

Anastasia Lubennikova writes: > Thank you for pointing out on specific of int4() function, > I updated tests to use dummy plpgsql function. > I'm not sure if tests of various join types are redundant but I left them. > As far as I understand, the principal motivation of this patch was to >

Re: Optimze usage of immutable functions as relation

26.07.2019 21:26, Tom Lane wrote: I took a quick look at this and I have a couple of gripes --- * The naming and documentation of transform_const_function_to_result seem pretty off-point to me. ISTM the real goal of that function is to pull up constant values from RTE_FUNCTION RTEs. Replacing

Re: Optimze usage of immutable functions as relation

I wrote: > * It would be useful for the commentary to point out that in principle we > could pull up any immutable (or, probably, even just stable) expression; > but we don't, (a) for fear of multiple evaluations of the result costing > us more than we can save, and (b) because a primary goal is

Re: Optimze usage of immutable functions as relation

Anastasia Lubennikova writes: > New version is in attachments. I took a quick look at this and I have a couple of gripes --- * The naming and documentation of transform_const_function_to_result seem pretty off-point to me. ISTM the real goal of that function is to pull up constant values from

Re: Optimze usage of immutable functions as relation

23.07.2019 14:36, Anastasia Lubennikova : 08.07.2019 4:18, Thomas Munro: The July Commitfest is here.  Could we please have a rebase of this patch? Updated patch is in attachments. I've only resolved one small cosmetic merge conflict. Later this week I'm going to send a more thoughtful

Re: Optimze usage of immutable functions as relation

08.07.2019 4:18, Thomas Munro: The July Commitfest is here. Could we please have a rebase of this patch? Updated patch is in attachments. I've only resolved one small cosmetic merge conflict. Later this week I'm going to send a more thoughtful review. -- Anastasia Lubennikova Postgres

Re: Optimze usage of immutable functions as relation

On Thu, Mar 21, 2019 at 5:58 AM Alexander Kuzmenkov wrote: > On 11/16/18 22:03, Tom Lane wrote: > > 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

Re: Optimze usage of immutable functions as relation

On 11/16/18 22:03, Tom Lane wrote: 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. Attached is a patch that

Re: Optimze usage of immutable functions as relation

On 3/5/19 20:22, David Steele wrote: I'll close this on March 8th if there is no new patch. This is taking longer than expected. I'll move it to the next commitfest and continue working on the patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian

Re: Re: Optimze usage of immutable functions as relation

On 2/28/19 4:27 PM, Alexander Kuzmenkov wrote: On 2/18/19 03:20, Tom Lane wrote: The dummy-relation stuff I referred to has now been merged, so there's really no good reason not to revise the patch along that line. I'll try to post the revised implementation soon. I'll close this on March

Re: Optimze usage of immutable functions as relation

On 2/18/19 03:20, Tom Lane wrote: The dummy-relation stuff I referred to has now been merged, so there's really no good reason not to revise the patch along that line. I'll try to post the revised implementation soon. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com

Re: Optimze usage of immutable functions as relation

Andres Freund writes: > Given this I think the appropriate state of the CF entry would have been > waiting-for-author, not needs review. Or alternatively > returned-with-feedback or rejected. I'm a bit confused as to why the > patch was moved to the next CF twice? We have this review from

Re: Optimze usage of immutable functions as relation

On 2018-11-08 15:08:03 +0100, Antonin Houska wrote: > Aleksandr Parfenov wrote: > > > I fixed a typo and some comments. Please find new version attached. > > I've checked this verstion too. > > * is_simple_stable_function() > > instead of fetching HeapTuple from the syscache manually, you

Re: Optimze usage of immutable functions as relation

Aleksandr Parfenov 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

Re: Optimze usage of immutable functions as relation

Aleksandr Parfenov wrote: > I fixed a typo and some comments. Please find new version attached. I've checked this verstion too. * is_simple_stable_function() instead of fetching HeapTuple from the syscache manually, you might want to consider using functions from lsyscache.c

Re: Optimze usage of immutable functions as relation

Kyotaro HORIGUCHI wrote: > I had the following error with the following query. > > =# explain select * from pg_stat_get_activity(NULL) a join log(10.0) p on > a.pid = p.p; > ERROR: no relation entry for relid 2 > I think that the problem is that RTE_VALUES is wrapped in a subquery by

Re: Optimze usage of immutable functions as relation

Hello. # It might be better that you provided self-contained test case. As the discussion between Heikki and Tom just upthread, it would be doable but that usage isn't typical. The query would be normally written as followings and they are transformed as desired. select '|'||subject||'|',

Re: Optimze usage of immutable functions as relation

Hi, Thank you for the review. I fixed a typo and some comments. Please find new version attached. --- Best regards, Parfenov Aleksandr On Fri, 19 Oct 2018 at 16:40, Anthony Bykov wrote: > The following review has been posted through the commitfest application: > make installcheck-world:

Re: Optimze usage of immutable functions as relation

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested Hello, I was trying to review your patch, but I couldn't install it:

Re: Optimze usage of immutable functions as relation

On Tue, 10 Jul 2018 17:34:20 -0400 Tom Lane wrote: >Heikki Linnakangas writes: >> But stepping back a bit, it's a bit weird that we're handling this >> differently from VALUES and other subqueries. The planner knows how >> to do this trick for simple subqueries: > >> postgres=# explain

Re: Optimze usage of immutable functions as relation

Heikki Linnakangas writes: > But stepping back a bit, it's a bit weird that we're handling this > differently from VALUES and other subqueries. The planner knows how to > do this trick for simple subqueries: > postgres=# explain select * from tenk1, (select abs(100)) as a (a) where > unique1

Re: Optimze usage of immutable functions as relation

On 16/05/18 13:47, Aleksandr Parfenov wrote: Hello, I reworked a patch to make more stable in different cases. I decided to use simplify_function instead of eval_const_expression to prevent inlining of the function. The only possible outputs of the simplify_function are Const node and NULL.

Re: Optimze usage of immutable functions as relation

Hello, I reworked a patch to make more stable in different cases. I decided to use simplify_function instead of eval_const_expression to prevent inlining of the function. The only possible outputs of the simplify_function are Const node and NULL. Also, I block pre-evaluation of functions with

Re: Optimze usage of immutable functions as relation

> "Aleksandr" == Aleksandr Parfenov writes: >> 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). Aleksandr>

Re: Optimze usage of immutable functions as relation

Hello Andrew, Thank you for the review of the patch. On Fri, 04 May 2018 08:37:31 +0100 Andrew Gierth wrote: > From an implementation point of view your patch is obviously broken in > many ways (starting with not checking varattno anywhere, and not > actually

Re: Optimze usage of immutable functions as relation

> "Aleksandr" == Aleksandr Parfenov 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>

Optimze usage of immutable functions as relation

Hi hackers, There is a strange behavior of the query planner in some cases if stable/immutable was used a relation. In some cases, it affects costs of operations and leads to a bad plan of the execution. Oleg Bartunov noticed such behavior in queries with a to_tsvector as a relation: =# explain