Re: Hints (was Poor performance using CTE) - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Hints (was Poor performance using CTE)
Date
Msg-id CAOR=d=0p+c8Ttwjo56CCU-kzxLZChpHkKg8C5K990krVHit-7w@mail.gmail.com
Whole thread Raw
In response to Re: Hints (was Poor performance using CTE)  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-performance
On Tue, Nov 27, 2012 at 7:17 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 27/11/2012 3:42 PM, Scott Marlowe wrote:
>
>> Here here!  PostgreSQL is well known for its extensibility and this is
>> the perfect place for hints.
>
> I agree with the sentiment and your concerns. However, this doesn't solve
> the CTE problem.
>
> Some people are relying on the planner's inability to push conditions into /
> pull conditions out of CTEs, and otherwise re-arrange them. If support for
> optimising into eligible CTEs (ie CTE terms that contain only SELECT or
> VALUES and call no VOLATILE functions) then these applications will
> potentially encounter serious performance regressions.
>
> Should this feature never be added to Pg, making it different and
> incompatible with other DBs that implement CTE optimisation, just because
> some people are using it for a hacky hint like OFFSET 0?

I'm strictly talking about any hinting mechanism being added being an
extension.  Fixing the planner so that optimizations can get cross the
CTE boundary seems the domain of back end hackers, not extensions.


pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Hints (was Poor performance using CTE)
Next
From: "Franklin, Dan"
Date:
Subject: Re: Savepoints in transactions for speed?