Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Fri, 12 Jul 2024 at 08:09, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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?

Unfortunately, this wouldn't align with the goals of the patch. Going
back to Melih's opening paragraph in the initial email, he mentions
that there's currently no *reliable* way to determine the parent/child
relationship in this view.

There's been a few different approaches to making this reliable. The
first patch had "parent_id" and "id" columns. That required a WITH
RECURSIVE query. To get away from having to write such complex
queries, the "path" column was born. I'm now trying to massage that
into something that's as easy to use and intuitive as possible. I've
gotta admit, I don't love the patch. That's not Melih's fault,
however. It's just the nature of what we're working with.

> 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.

I don't think it's ideal that the context's ID changes in ad-hoc
queries, but I don't know how to make that foolproof. The
breadth-first ID assignment helps, but it could certainly still catch
people out when the memory context of interest is nested at some deep
level. The breadth-first certainly assignment helped me with the
CacheMemoryContext that I'd been testing with. It allowed me to run my
aggregate query to sum the bytes without the context created in
nodeAgg.c causing the IDs to change.

I'm open to better ideas on how to make this work, but it must meet
the spec of it being a reliable way to determine the context
relationship. If names were unique at each level having those instead
of IDs might be nice, but as Melih demonstrated, they're not. I think
even if Melih's query didn't return results, it would be a bad move to
make it work the way you mentioned if we have nothing to enforce the
uniqueness of names.

David