| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CTE inlining |
| Date: | 2017-05-01 13:46:02 |
| Message-ID: | CAMsr+YEkOjHEsGbHAPy0ki0WSD1-KkQEiq8LO_EJFcoyodMTqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1 May 2017 at 21:22, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> Having had years of telling users that CTEs are an optimization fence it
> doesn't seem at all nice for us to turn around and change our mind about
> that. I have relied on it in the past and I'm sure I'm very far from
> alone in that.
>
> Maybe we could allow a "decorator" that would tell the planner the CTE
> could be inlined?
>
> WITH INLINE mycte AS ( ...)
I'd rather reverse that so we behave like other implementations by
default, and have extension syntax for our no-inline query hint. And
yes, that's what it is, because we'd only inline when we could produce
semantically equivalent results anyway.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neha Khatri | 2017-05-01 13:51:02 | Description of create_singleton_array() |
| Previous Message | Andrew Dunstan | 2017-05-01 13:39:54 | check with serial |