On Fri, 12 Jul 2024 at 08:09, Robert Haas <robertmh...@gmail.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
