Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
Дата
Msg-id CAGTBQpahSrrddk1T9UPG6rkDWW6mzB_Hn2gJ=fyp1gbq1Mrt_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?  (Craig James <craig_james@emolecules.com>)
Список pgsql-performance
On Wed, Nov 2, 2011 at 12:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I wonder if we need to rethink, though.  We've gotten a number of
> reports of problems that were caused by single-use CTEs not being
> equivalent - in terms of performance - to a non-CTE formulation of the
> same idea.  It seems necessary for CTEs to behave this way when the
> subquery modifies data, and there are certainly situations where it
> could be desirable otherwise, but I'm starting to think that we
> shouldn't do it that way by default.  Perhaps we could let people say
> something like WITH x AS FENCE (...) when they want the fencing
> behavior, and otherwise assume they don't (but give it to them anyway
> if there's a data-modifying operation in there).

Well, in my case, I got performance thanks to CTEs *being*
optimization fences, letting me fiddle with query execution.

And I mean, going from half-hour queries to 1-minute queries.

It is certainly desirable to maintain the possibility to use fences when needed.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Intel 710 pgbench write latencies