Tom,
Thank you so much for your help. Upgrading to 8.1.5 did the trick, the
query now has a better plan, and executes quickly:
QUERY PLAN
Chris Tennant <[EMAIL PROTECTED]> writes:
> ... the underlying problem remains: even
> with the correct function definition, the query executes thousands of
> times slower on 7.4 than on 7.3
Well, note that 7.4 thinks it's finding a *better* plan --- the
estimated cost is about half what it was
doh. I copied an earlier definition of the function into the email.
Thanks for catching my (moronic) error, and my apologies for distracting
everyone on the list. However, the underlying problem remains: even
with the correct function definition, the query executes thousands of
times slower
Chris Tennant <[EMAIL PROTECTED]> writes:
> here's the definition of the function (as immutable):
> CREATE OR REPLACE FUNCTION stereo_id (INTEGER, INTEGER, INTEGER) RETURNS
> INTEGER AS
> 'BEGIN RETURN CASE WHEN $2 = $3 THEN $1 ELSE -1 END;END;'
>LANGUAGE 'plpgsql' IMMUTABLE;
> and
Greetings,
I've just upgraded from 7.3.6 to 7.4.7 (running on Debian Linux). I
dumped and reloaded my db as part of the upgrade. Everything is working
great, except that one query that executed in < 1 ms on 7.3.6 now takes
> 500 ms on 7.4.7. When I look at the query plan, the planner is no
