Re: Horrible/never returning performance using stable function on WHERE clause

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Horrible/never returning performance using stable function on WHERE clause
Date: 2016-03-29 11:04:15
Message-ID: CAKJS1f_dKdSpostuxL+FNeA0EiUD85BjzWVXrJ3S0B4YviUkwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 29 March 2016 at 20:01, Achilleas Mantzios
<achill(at)matrix(dot)gatewaynet(dot)com> wrote:
> We are using PostgreSQL 9.3. Shouldn't the optimizer use a single call to
> get_machdef_sister_defids in get_machdef_sister_defids_maxrh ??

It shouldn't be up to the optimizer to evaluate a STABLE function.
Only IMMUTABLE functions will be evaluated during planning.

What's not that clear to me is if the planner might be able to work a
bit harder to create an "Initplan" for stable functions with Const
arguments. Right now I can't quite see a reason why that couldn't be
improved upon, after all, the documentation does claim that a STABLE
function during a "single table scan it will consistently return the
same result for the same argument values".

However it would be quite simple just for you to force the STABLE
function to be evaluated once, instead of once per row, just by
modifying your query to become:

select max(rh) into tmp from items where vslwhid=vvslid and
itoar(defid) ~ (select get_machdef_sister_defids(vdefid));

Viewing the EXPLAIN of this, you'll notice the InitPlan, which will
evaluate the function and allow the use the output value as a
parameter in the main query.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sridhar N Bamandlapally 2016-03-29 11:37:38 Re: pg_largeobject
Previous Message Geoff Winkless 2016-03-29 10:47:40 Re: More correlated (?) index woes