Re: Explain and filter over subplans - Mailing list pgsql-general

From Tom Lane
Subject Re: Explain and filter over subplans
Date
Msg-id 2289721.1705600540@sss.pgh.pa.us
Whole thread Raw
In response to Explain and filter over subplans  (Chantal Keller <chantal.keller@universite-paris-saclay.fr>)
Responses Re: Explain and filter over subplans  (Chantal Keller <chantal.keller@universite-paris-saclay.fr>)
List 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 by date:

Previous
From: Jim Vanns
Date:
Subject: Re: Tips on troubleshooting slow DELETE (suspect cascades)
Next
From: Martin Ritchie
Date:
Subject: Re: Tips on troubleshooting slow DELETE (suspect cascades)