| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: CTE inlining |
| Date: | 2017-05-01 14:26:22 |
| Message-ID: | b9ff8365-95af-e1ed-3c41-f2a778b78d77@proxel.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05/01/2017 04:17 PM, David Fetter wrote:
>> Maybe we could allow a "decorator" that would tell the planner the CTE
>> could be inlined?
>>
>> WITH INLINE mycte AS ( ...)
>
> +1 for a decorator, -1 for this one.
I am not sure I like decorators since this means adding an ad hoc query
hint directly into the SQL syntax which is something which I requires
serious consideration.
> We already have an explicit optimization fence with OFFSET 0, and I
> think making optimization fences explicit is how we should continue.
> I'd be more in favor of something along the lines of
>
> WITH FENCED /* Somewhat fuzzy. What fence? */
> or
> WITH AT_MOST_ONCE /* Clearer, but not super precise */
> or
> WITH UNIQUE_ATOMIC /* More descriptive, but not super clear without the docs in hand */
>
> or something along that line.
What about WITH MATERIALIZED, borrowing from the MySQL terminology
"materialized subquery"?
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2017-05-01 14:33:26 | Re: CTE inlining |
| Previous Message | Robert Haas | 2017-05-01 14:20:38 | Re: PG 10 release notes |