Re: Report planning memory in EXPLAIN ANALYZE - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Report planning memory in EXPLAIN ANALYZE
Date
Msg-id 202312122011.glue4ur4ajb4@alvherre.pgsql
Whole thread Raw
In response to Re: Report planning memory in EXPLAIN ANALYZE  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Report planning memory in EXPLAIN ANALYZE
Re: Report planning memory in EXPLAIN ANALYZE
List pgsql-hackers
I would replace the text in explain.sgml with this:

+      Include information on memory consumption by the query planning phase.
+      This includes the precise amount of storage used by planner in-memory
+      structures, as well as overall total consumption of planner memory,
+      including allocation overhead.
+      This parameter defaults to </literal>FALSE</literal>.

and remove the new example you're adding; it's not really necessary.

In struct ExplainState, I'd put the new member just below summary.

If we're creating a new memory context for planner, we don't need the
"mem_counts_start" thing, and we don't need the
MemoryContextSizeDifference thing.  Just add the
MemoryContextMemConsumed() function (which ISTM should be just below
MemoryContextMemAllocated() instead of in the middle of the
MemoryContextStats implementation), and
just report the values we get there.  I think the SizeDifference stuff
increases surface damage for no good reason.

ExplainOnePlan() is given a MemoryUsage object (or, if we do as above
and no longer have a MemoryUsage struct at all in the first place, a
MemoryContextCounters object) even when the MEMORY option is false.
This means we waste computing memory usage when not needed.  Let's avoid
that useless overhead.

I'd also do away with the comment you added in explain_ExecutorEnd() and
do just this, below setting of es->summary:

+           /* No support for MEMORY option */
+           /* es->memory = false; */

We don't need to elaborate more at present.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Doing what he did amounts to sticking his fingers under the hood of the
implementation; if he gets his fingers burnt, it's his problem."  (Tom Lane)



pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Move walreceiver state assignment (to WALRCV_STREAMING) in WalReceiverMain()
Next
From: Alvaro Herrera
Date:
Subject: Re: Report planning memory in EXPLAIN ANALYZE