From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Rogers <teukros(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CTE optimization fence on the todo list? |
Date: | 2015-05-01 22:59:42 |
Message-ID: | 5544055E.6070308@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/1/15 6:32 PM, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-05-01 23:10:31 | Re: Improving replay of XLOG_BTREE_VACUUM records |
Previous Message | Jim Nasby | 2015-05-01 22:55:48 | Re: Reducing tuple overhead |