| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Greco <David_Greco(at)harte-hanks(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: SOLVED - RE: Poor performance using CTE |
| Date: | 2012-11-20 19:22:50 |
| Message-ID: | CAHyXU0yPcfWQ58yU07vhit2PQ70kcxsDOr7QumZgvnKT=fcC-Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Nov 14, 2012 at 8:03 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 15 November 2012 01:46, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> It cuts both ways. I have used CTEs a LOT precisely because this behaviour
>> lets me get better plans. Without that I'll be back to using the "offset 0"
>> hack.
>
> Is the "OFFSET 0" hack really so bad? We've been telling people to do
> that for years, so it's already something that we've effectively
> committed to.
IMSNHO, 'OFFSET 0' is completely unreadable black magic. I agree with
Andrew: CTEs allow for manual composition of queries and can be the
best tool when the planner is outsmarting itself. In the old days,
we'd extract data to a temp table and join against that: CTE are
essentially a formalization of that technique. I like things the way
they are; if CTE are hurting your plan, that's an indication you're
using them inappropriately.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2012-11-20 19:26:09 | Re: SOLVED - RE: Poor performance using CTE |
| Previous Message | Claudio Freire | 2012-11-20 16:06:40 | Re: Poor performance using CTE |