| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndQuadrant(dot)com> |
| Cc: | David Greco <David_Greco(at)harte-hanks(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: SOLVED - RE: Poor performance using CTE |
| Date: | 2012-11-15 01:31:14 |
| Message-ID: | 1159.1352943074@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Craig Ringer <craig(at)2ndQuadrant(dot)com> writes:
> I was looking through the latest spec drafts I have access to and
> couldn't find any reference to Pg's optimisation-fence-for-CTEs
> behaviour being required by the standard, though I've repeatedly seen it
> said that there is such a requirement.
I don't believe it's required by the standard (it's hard to see how it
could be, when query optimization is a topic outside the spec to start
with). However, we allow INSERT/UPDATE/DELETE RETURNING inside WITH,
and for those I think you really need to treat WITH as an optimization
fence. It's a lot more debatable for SELECT; there are some advantages
to providing a fence this way but there are definitely downsides too.
I could see adjusting that definition in the future, as we get more
experience with use of CTEs.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-11-15 01:46:37 | Re: SOLVED - RE: Poor performance using CTE |
| Previous Message | Craig Ringer | 2012-11-15 01:17:28 | Re: SOLVED - RE: Poor performance using CTE |