Re: unexpected stable function behavior

From: Julius Tuskenis <julius(at)nsoft(dot)lt>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: unexpected stable function behavior
Date: 2011-03-14 08:46:07
Message-ID: 4D7DD5CF.4080502@nsoft.lt
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello, Merlin

Thank you for your quick response.

2011.03.10 23:14, Merlin Moncure rašė:
> This is a huge problem with non trivial functions in the select list.
> Pushing the result into and a subquery does NOT guarantee that the
> inner result is materialized first.
From the postgresql documentation about STABLE functions: "This
category allows the optimizer to optimize multiple calls of the function
to a single call." I thought that this means that optimizer executes the
function only for now parameter sets and stores results in some "cache"
and use it if the parameters are already known. I realize this is very
naive approach and most probably everything is much more complicated. I
would appreciate if someone would explain the mechanism (or provide with
some useful link).

> Try a CTE.
>
> with foo as
> (
> select yadda;
> )
> select func(foo.a), foo.* from foo;
I'm sorry, but I'm totally new to CTE. Would you please show me how
should I use the stable function and where the parameters should be put
to improve the behavior of the optimizer for my problem?

Thank you in advance

--
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message John Surcombe 2011-03-14 09:37:40 Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
Previous Message Tom Lane 2011-03-13 22:10:29 Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1