Re: CTE optimization fence on the todo list?
От | Merlin Moncure |
---|---|
Тема | Re: CTE optimization fence on the todo list? |
Дата | |
Msg-id | CAHyXU0zpM5+Dsb_pKxDmm-ZoWUAt=SkHHaiK_DBqcmtxTas6Nw@mail.gmail.com обсуждение исходный текст |
Ответ на | CTE optimization fence on the todo list? (Daniel Browning <db@kavod.com>) |
Ответы |
Re: CTE optimization fence on the todo list?
Re: CTE optimization fence on the todo list? Re: CTE optimization fence on the todo list? |
Список | pgsql-hackers |
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning <db@kavod.com> wrote: > Another good reason to reject it might be because the only way to disable > the CTE fence is to disable it by default. If that were the case, then I > would imagine that it would break backwards compatibility, especially in the > case of writable CTEs that currently depend on the fence for their current > functionality. Yeah: I constantly rely on CTE fencing and it's a frequently suggested performance trick on the lists. LATERAL is coming out soon and this will remove one of the largest reasons to fence but there are of course others. Also, a GUC setting is almost certainly the wrong approach. I'm wondering if there are any technical/standards constraints that are behind the fencing behavior. If there aren't any, maybe an opt-in keyword might do the trick -- WITH UNBOXED foo AS (..)? merlin
В списке pgsql-hackers по дате отправления: