Re: Our trial to TPC-DS but optimizer made unreasonable plan

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

In response to

Browse pgsql-hackers by date

  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