Re: [HACKERS] CTE inlining
| От | David G. Johnston |
|---|---|
| Тема | Re: [HACKERS] CTE inlining |
| Дата | |
| Msg-id | CAKFQuwayrvy8F00DJh-P-PXMG7Vjv3Qzb=o-gr89s=SjZ_OZ=w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] CTE inlining (Andreas Karlsson <andreas@proxel.se>) |
| Ответы |
Re: [HACKERS] CTE inlining
|
| Список | 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.
Given that we already have
"
prevent optimization"
syntax why do we need a decorator on the CTE?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"?
I would shorten that to "WITH MAT" except that I don't think that having two way to introduce an optimization fence is worthwhile.
If we don't optimize SRFs-in-target-list, and thus avoid multiple function evaluation for (composite_col).*, I believe a significant number of intentional optimization fence uses will be safe but behavioral changes.
David J.
В списке pgsql-hackers по дате отправления: