Re: Poor performance using CTE

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndQuadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, David Greco <David_Greco(at)harte-hanks(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Poor performance using CTE
Date: 2012-11-21 14:47:12
Message-ID: 50ACE970.7050701@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On 11/21/2012 08:04 AM, Heikki Linnakangas wrote:
> On 21.11.2012 01:53, Tom Lane wrote:
>> I think the more interesting question is what cases wouldn't be covered
>> by such a rule. Typically you need to use OFFSET 0 in situations where
>> the planner has guessed wrong about costs or rowcounts, and I think
>> people are likely using WITH for that as well. Should we be telling
>> people that they ought to insert OFFSET 0 in WITH queries if they want
>> to be sure there's an optimization fence?
>
> Yes, I strongly feel that we should. Writing a query using WITH often
> makes it more readable. It would be a shame if people have to refrain
> from using it, because the planner treats it as an optimization fence.
>
>

If we're going to do it can we please come up with something more
intuitive and much, much more documented than "OFFSET 0"? And if/when we
do this we'll need to have big red warnings all over then release notes,
since a lot of people I know will need to do some extensive remediation
before moving to such a release.

cheers

andrew

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2012-11-21 14:59:07 Re: Poor performance using CTE
Previous Message Kevin Grittner 2012-11-21 13:42:32 Re: Hints (was Poor performance using CTE)