Re: Function execution costs 'n all that
| От | Tom Lane |
|---|---|
| Тема | Re: Function execution costs 'n all that |
| Дата | |
| Msg-id | 15293.1169081431@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Function execution costs 'n all that (Jeff Davis <pgsql@j-davis.com>) |
| Список | pgsql-hackers |
Jeff Davis <pgsql@j-davis.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
В списке pgsql-hackers по дате отправления: