From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parent/child context relation in pg_get_backend_memory_contexts() |
Date: | 2024-07-15 11:38:32 |
Message-ID: | CAApHDvo4SENSeh72PL_=y6q=Hyta4a-op_rVSh+18fm_RYdRCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 13 Jul 2024 at 10:12, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> wrote:
> I updated documentation for path and level columns and also fixed the tests as level starts from 1.
Thanks for updating.
+ The <structfield>path</structfield> column can be useful to build
+ parent/child relation between memory contexts. For example, the following
+ query calculates the total number of bytes used by a memory context and its
+ child contexts:
"a memory context" doesn't quite sound specific enough. Let's say what
the query is doing exactly.
+<programlisting>
+WITH memory_contexts AS (
+ SELECT *
+ FROM pg_backend_memory_contexts
+)
+SELECT SUM(total_bytes)
+FROM memory_contexts
+WHERE ARRAY[(SELECT path[array_length(path, 1)] FROM memory_contexts
WHERE name = 'CacheMemoryContext')] <@ path;
I don't think that example query is the most simple example. Isn't it
better to use the most simple form possible to express that?
I think it would be nice to give an example of using "level" as an
index into "path"
WITH c AS (SELECT * FROM pg_backend_memory_contexts)
SELECT sum(c1.total_bytes)
FROM c c1, c c2
WHERE c2.name = 'CacheMemoryContext'
AND c1.path[c2.level] = c2.path[c2.level];
I think the regression test query could be done using the same method.
>> + while (queue != NIL)
>> + {
>> + List *nextQueue = NIL;
>> + ListCell *lc;
>> +
>> + foreach(lc, queue)
>> + {
>
>
> I don't think we need this outer while loop. Appending to the end of a queue naturally results in top-to-bottom order anyway, keeping two lists, "queue" and "nextQueue", might not be necessary. I believe that it's safe to append to a list while iterating over that list in a foreach loop. v9 removes nextQueue and appends directly into queue.
The foreach() macro seems to be ok with that. I am too. The following
comment will need to be updated:
+ /*
+ * Queue up all the child contexts of this level for the next
+ * iteration of the outer loop.
+ */
That outer loop is gone.
Also, this was due to my hasty writing of the patch. I named the
function get_memory_context_name_and_indent. I meant to write "ident".
If we did get rid of the "parent" column, I'd not see any need to keep
that function. The logic could just be put in
PutMemoryContextsStatsTupleStore(). I just did it that way to avoid
the repeat.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-07-15 11:39:10 | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |
Previous Message | Stepan Neretin | 2024-07-15 11:07:48 | Re: Patch bug: Fix jsonpath .* on Arrays |