Re: SOLVED - RE: Poor performance using CTE

On Tue, Nov 20, 2012 at 5:24 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Nov 20, 2012 at 1:53 PM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
>> As can be seen by the current conversation, not everyone is convinced
> that CTEs ought to be an explicit optimization barrier
>
> On Tue, Nov 20, 2012 at 1:26 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> It *could* just be a lack of imagination on my part. But if it were
>> not, then it'd be nice for it to be done automatically (since this
>> particular CTE behavior bites enough people already).
>
> Sure. I just find it personally hard to find a good demarcation line
> between A: "queries where pushing quals through are universally
> beneficial and wanted" and B: "queries where we are inserting an
> explicit materialization step to avoid planner issues", particularly
> where there is substantial overlap with between A and C: "queries that
> are written with a CTE and arguably shouldn't be".
>
> Put another way, I find CTE to express: 'this then that' where joins
> express 'this with that'. So current behavior is not surprising at
> all. All that said, there could be a narrow class of low hanging cases
> (such as the OP's) that could be sniped...I'm just skeptical.

It could work very well towards CTE-including views, where the quals
cannot be added in the view but would be present when the view is
expanded in final queries.