Re: Invalid optimization of VOLATILE function in WHERE clause?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Invalid optimization of VOLATILE function in WHERE clause?
Дата
Msg-id CA+Tgmoaeb9c4BFr=6ZPgtDCivmrajU8=qjPwk5e3R+3GjxYp9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Invalid optimization of VOLATILE function in WHERE clause?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Invalid optimization of VOLATILE function in WHERE clause?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Sep 19, 2012 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Sep 19, 2012 at 10:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> To do what you want, I'd suggest wrapping the join into a sub-select
>>> with an "OFFSET 0" clause, which will serve as an optimization fence
>>> that prevents the random() call from being pushed down.
>
>> You've repeatedly objected to complaints on pgsql-performance on the
>> grounds that WITH is an optimization fence.  It seems awfully
>> inconsistent to turn around and say, oh, sometimes it's not a fence
>> after all.
>
> Huh?  The join in question is not inside a WITH.  If it were, that
> would work too, as noted by Merlin.

Oh, hmm.  I see now: the problem isn't that random() is being pushed
into the WITH, it's that it's being pushed into the join.  Sorry, I
should have read that more carefully.

It still seems like awfully weird behavior.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Invalid optimization of VOLATILE function in WHERE clause?
Следующее
От: Tom Lane
Дата:
Сообщение: Removal of AcceptInvalidationMessages broke things