Re: Parent/child context relation in pg_get_backend_memory_contexts() - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: Parent/child context relation in pg_get_backend_memory_contexts()
Date
Msg-id CAGPVpCRA7A_rhDYKm9oLrRPDWU0oZ8jxyffGk3HwOzNxJSi0tw@mail.gmail.com
Whole thread Raw
In response to Re: Parent/child context relation in pg_get_backend_memory_contexts()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parent/child context relation in pg_get_backend_memory_contexts()
Re: Parent/child context relation in pg_get_backend_memory_contexts()
List pgsql-hackers
Hi Robert,

Robert Haas <robertmhaas@gmail.com>, 11 Tem 2024 Per, 23:09 tarihinde şunu yazdı:
> Ideally, no CTE would be needed here, but unfortunately, there's no
> way to know the CacheMemoryContext's ID beforehand.  We could make the
> ID more stable if we did a breadth-first traversal of the context.
> i.e., assign IDs in level order.  This would stop TopMemoryContext's
> 2nd child getting a different ID if its first child became a parent
> itself.

Do we ever have contexts with the same name at the same level? Could
we just make the path an array of strings, so that you could then say
something like this...

SELECT * FROM pg_backend_memory_contexts where path[2] = 'CacheMemoryContext'

...and get all the things with that in the path?

I just ran the below  to see if we have any context with the same level and name.

postgres=# select level, name, count(*) from pg_backend_memory_contexts group by level, name having count(*)>1;
 level |    name     | count
-------+-------------+-------
     3 | index info  |    90
     5 | ExprContext |     5

Seems like it's a possible case. But those contexts might not be the most interesting ones. I guess the contexts that most users would be interested in will likely be unique on their levels and with their name. So we might not be concerned with the contexts, like those two from the above result, and chose using names instead of transient IDs. But I think that we can't guarantee name-based path column would be completely reliable in all cases.
 
> select * from pg_backend_memory_contexts;
> -- Observe that CacheMemoryContext has ID=22 and level=2. Get the
> total of that and all of its descendants.
> select sum(total_bytes) from pg_backend_memory_contexts where path[2] = 22;
> -- or just it and direct children
> select sum(total_bytes) from pg_backend_memory_contexts where path[2]
> = 22 and level <= 3;

I'm doubtful about this because nothing prevents the set of memory
contexts from changing between one query and the next. We should try
to make it so that it's easy to get what you want in a single query.

Correct. Nothing will not prevent contexts from changing between each execution. With David's change to use breadth-first traversal, contexts at upper levels are less likely to change. Knowing this may be useful in some cases. IMHO there is no harm in making those IDs slightly more "stable", even though there is no guarantee. My concern is whether we should document this situation. If we should, how do we explain that the IDs are transient and can change but also may not change if they're closer to TopMemoryContext? If it's better not to mention this in the documentation, does it really matter since most users would not be aware? 


I've been also thinking if we should still have the parent column, as finding out the parent is also possible via looking into the path. What do you think?

Thanks,
--
Melih Mutlu
Microsoft

pgsql-hackers by date:

Previous
From: Ilya Gladyshev
Date:
Subject: Re: CREATE INDEX CONCURRENTLY on partitioned index
Next
From: Noah Misch
Date:
Subject: Re: MAINTAIN privilege -- what do we need to un-revert it?