Re: Function execution costs 'n all that

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Richard Troy <rtroy(at)ScienceTools(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Function execution costs 'n all that
Date: 2007-01-18 00:50:31
Message-ID: 15293.1169081431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Would any form of cost estimate have meaning if the function has side
> effects? If it's a volatile function, doesn't that mean that the planner
> can't avoid or favor executing it?

No, not really. If the function is down inside a sub-select or
something like that, the number of executions could depend on any number
of factors (like whether we put it on the inside or outside of a join)
--- and if it's expensive then we will and should try to arrange the
query to minimize the number of executions. We're certainly not going
to drop back to all-plain-nestloops just because the query contains one
volatile function.

(Now mind you, a smart user will probably avoid using a volatile
function like that, but I don't think it's an adequate argument for
saying that we don't need cost information.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2007-01-18 00:53:13 Re: Design notes for EquivalenceClasses
Previous Message Tom Lane 2007-01-18 00:46:04 Re: Design notes for EquivalenceClasses