"Obe, Regina" <[EMAIL PROTECTED]> writes:
> It would be really nice if this worked with OR as well. Is it just much
> harder to deal with the
> OR case in the planner or was there some other reason why the OR case
> was left out?
Nobody's really made a case why we should have the planner expend
> > --Test 2: This works as I would expect - shows that none of the
> > functions are run presumably its going straight for 5 > 2
> > --becuase it recognizes its the cheapest route
> > TRUNCATE TABLE log_call;
> > SELECT foo.value
> > FROM (SELECT (fn_pg_costlyfunction() > 2 OR fn_pg_cheapfunctio
"Obe, Regina" <[EMAIL PROTECTED]> writes:
> --Test 1: This shows that fn_pg_costlyfunction() is the only function
> that is run -
> -- unexpected to me shouldn't no function be evaluated or the cheap one?
> --What's the difference between Test 1 and Test 2 that makes Test 2 do
> the RIGHT thing?
>
I think I am missing something about how the new CREATE OR REPLACE
FUNCTION ...COST works or I am missing some setting in postgresql conf.
I was hoping I could use it to control the function that is used in
cases where only one needs to be evaluated. Regardless of what I do it
seems to always ev
