Re: Explain and filter over subplans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Explain and filter over subplans
Дата
Msg-id 2289721.1705600540@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Explain and filter over subplans  (Chantal Keller <chantal.keller@universite-paris-saclay.fr>)
Ответы Re: Explain and filter over subplans
Список pgsql-general
Chantal Keller <chantal.keller@universite-paris-saclay.fr> writes:
> I would like "explain" to output formulas for filtering over
> subplans. Is it possible?

No, and that's been a to-do item for a long time.

Currently, EXPLAIN just ignores the "testexpr" field of SubPlan
nodes, which is what you are after.  We could print it, if we
could figure out an intelligible representation.  In the example
you give, the testexpr would probably render as "t.a >= $0"
where $0 represents the subplan's output column.

A very rough sketch, perhaps, is that instead of just
"(SubPlan 1)", we could print "(ALL t.a >= $0 FROM SubPlan 1)".
Some of the other SubLinkTypes might be harder to represent
in a way that makes sense to users.

I made a quick-hack patch to play with, if you're interested.

            regards, tom lane

diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 0b2a164057..5b81e2c4cf 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -8869,12 +8869,43 @@ get_rule_expr(Node *node, deparse_context *context,
                  * We cannot see an already-planned subplan in rule deparsing,
                  * only while EXPLAINing a query plan.  We don't try to
                  * reconstruct the original SQL, just reference the subplan
-                 * that appears elsewhere in EXPLAIN's result.
+                 * that appears elsewhere in EXPLAIN's result.  It does seem
+                 * useful to show the testexpr, however, and we also note
+                 * whether the subplan will be hashed.
                  */
+                switch (subplan->subLinkType)
+                {
+                    case EXISTS_SUBLINK:
+                        appendStringInfoString(buf, "(EXISTS");
+                        break;
+                    case ALL_SUBLINK:
+                        appendStringInfoString(buf, "(ALL ");
+                        break;
+                    case ANY_SUBLINK:
+                        appendStringInfoString(buf, "(ANY ");
+                        break;
+                    case ROWCOMPARE_SUBLINK:
+                        appendStringInfoString(buf, "(ROWCOMPARE ");
+                        break;
+                    case EXPR_SUBLINK:
+                        appendStringInfoString(buf, "(EXPR");
+                        break;
+                    case MULTIEXPR_SUBLINK:
+                        appendStringInfoString(buf, "(MULTIEXPR");
+                        break;
+                    case ARRAY_SUBLINK:
+                        appendStringInfoString(buf, "(ARRAY");
+                        break;
+                    case CTE_SUBLINK:
+                        /* This case is probably unreachable */
+                        appendStringInfoString(buf, "(CTE");
+                        break;
+                }
+                get_rule_expr(subplan->testexpr, context, showimplicit);
                 if (subplan->useHashTable)
-                    appendStringInfo(buf, "(hashed %s)", subplan->plan_name);
+                    appendStringInfo(buf, " FROM hashed %s)", subplan->plan_name);
                 else
-                    appendStringInfo(buf, "(%s)", subplan->plan_name);
+                    appendStringInfo(buf, " FROM %s)", subplan->plan_name);
             }
             break;


В списке pgsql-general по дате отправления:

Предыдущее
От: Jim Vanns
Дата:
Сообщение: Re: Tips on troubleshooting slow DELETE (suspect cascades)
Следующее
От: Martin Ritchie
Дата:
Сообщение: Re: Tips on troubleshooting slow DELETE (suspect cascades)