Re: Parent/child context relation in pg_get_backend_memory_contexts()

Hi Robert,

Robert Haas <robertmhaas(at)gmail(dot)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