Re: CTE optimization fence on the todo list?
От | David Steele |
---|---|
Тема | Re: CTE optimization fence on the todo list? |
Дата | |
Msg-id | 5544055E.6070308@pgmasters.net обсуждение исходный текст |
Ответ на | Re: CTE optimization fence on the todo list? (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On 5/1/15 6:32 PM, Peter Geoghegan wrote: > On Fri, May 1, 2015 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Assuming that that sketch is accurate, it would take more code to provide >> a new user-visible knob to enable/disable the behavior than it would to >> implement the optimization, which makes me pretty much -1 on providing >> such a knob. We should either do it or not. If we do, people who want >> optimization fences should use the traditional "OFFSET 0" hack. > > +1 Not sure if I'm thrilled with the "OFFSET 0" hack but I guess it's not much different from the CTE hack I've been using. An "enable_cte_optimization" GUC would serve to keep old code from breaking while giving new users/queries the advantage of optimization. I'm not sure it's worth adding the complexity, though. In my experience not that many developers use CTEs. -- - David Steele david@pgmasters.net
В списке pgsql-hackers по дате отправления: