From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Our trial to TPC-DS but optimizer made unreasonable plan |
Date: | 2015-08-31 16:36:32 |
Message-ID: | 20150831163632.GB31526@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-08-19 15:14:03 -0700, Josh Berkus wrote:
> Asking users to refactor their applications to add OFFSET 0 is a bit
> painful, if we could take care of it via a backwards-compatibility GUC.
> We have many users who are specifically using the CTE optimization
> barrier to work around planner failures.
Agreed. I think we'll cause a lot of problems in migrations if we do
this unconditionally. I also think CTEs are a much cleaner optimization
barrier than OFFSET 0.
Some are probably going to hate me for this, but I think it'd be better
to change the grammar to something like
name opt_name_list AS '(' PreparableStmt ')' OPTIONS '(' cte_option_list ')'
and allow to specify 'inline' 'off'/'on'. The guc would simply change
the default value.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | YUriy Zhuravlev | 2015-08-31 16:42:19 | Re: Scaling PostgreSQL at multicore Power8 |
Previous Message | Qingqing Zhou | 2015-08-31 16:26:50 | Re: Our trial to TPC-DS but optimizer made unreasonable plan |