| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | 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-20 16:06:40 |
| Message-ID: | CAGTBQpbf9bdJ3gjcYdw2FuPmN=dqx+wE7opsCp515cEndpGDYw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Nov 20, 2012 at 12:23 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Nov 20, 2012 at 9:10 AM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> On Tue, Nov 20, 2012 at 12:04 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> The problem here is very clear. Oracle is optimizing through the CTE.
>>> PostgreSQL does not do this by design -- CTE's are used as a forced
>>> materialization step.
>>
>> While I love that design (it lets me solve lots of problems for huge
>> queries), wouldn't pushing constraints into the CTE be a rather safe
>> optimization?
>
> sure, or rewrite query as classic join.
I meant for postgres to do automatically. Rewriting as a join wouldn't
work as an optimization fence the way we're used to, but pushing
constraints upwards can only help (especially if highly selective).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2012-11-20 19:22:50 | Re: SOLVED - RE: Poor performance using CTE |
| Previous Message | Merlin Moncure | 2012-11-20 15:23:50 | Re: Poor performance using CTE |