Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Дата
Msg-id 2721.1427062576@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch  ("Paragon Corporation" <lr@pcorp.us>)
Ответы Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch  ("Paragon Corporation" <lr@pcorp.us>)
Список pgsql-bugs
"Paragon Corporation" <lr@pcorp.us> writes:
> Guys I tried increasing cost with the ST_Reclass function to 2000 and it didn't help.  The function is called for
everysingle output.    The only thing that helps is setting this to VOLATILE as Tom suggests.  I guess we can do that
assome sort of fix for these kinds of functions though I'm not sure if that would cause other issues. 

I think that would be a very bad idea; it would foreclose optimizations
that you *do* want.  Much better, if you are relying on single-evaluation
behavior for a non-volatile function, is to use one of the documented
optimization fences: either a CTE, or an OFFSET 0 in a sub-select.

TBH, this particular example does not fill me with concern, because
(a) it's obviously artificial, and (b) you'd really never notice if the
function got evaluated 3 times not once, if you hadn't put in that NOTICE.
I grant that there may be cases where you're worried about avoiding
multiple evaluations *per row* over some large number of rows, but to
discuss that type of problem we'd have to see what your coding habits are
like for such cases.  An immutable function being fed constants is not
going to create that type of problem.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Paragon Corporation"
Дата:
Сообщение: Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch
Следующее
От: "Paragon Corporation"
Дата:
Сообщение: Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch