> > Not sure if you already had a place in mind, but thinking through > > where we could attach it, I realized two things: > > > > 1) QueryDesc seems like a reasonable struct to communicate nesting > > level (since it gets passed to the relevant executor hooks already), > > but that doesn't get passed to ProcessUtility today > > 2) ProcessUtility has an existing indicator for top-level statements > > in ProcessUtilityContext (PROCESS_UTILITY_TOPLEVEL) > > > > Were you thinking of actually using a backend struct (i.e. > > PgBackendStatus) and keep changing that as we run through the > > different execution levels, and exposing a helper function to retrieve > > it? > > I did not have in mind a backend structure with a state allocated for > as long as the session lives would be a good fit. It is a bit better > than a static flag to drive the decisions, but it is still open to > being incorrect because it would require more code paths to reset it. > Something like QueryDesc would be a better fit, for a state that > sticks for as long as a top-level transaction is running. We are not > doing that stuff really well yet, though, if we want to track data > like a nesting level. So my short answer is that I do not know yet > what a good answer is, but it is definitely a problem to have some > duplicated logic to calculate a nesting level across many extensions. > QueryDesc was one that popped in mind, like you, but I got reminded > that utility.c has no idea about that, so... Now QueryDesc knows > about a PlannedStmt, which is something that utility.c knows.
Before going down the fix in pg_stat_statements directly, it did cross my mind about doing nesting_level tracking in core, but I was not sure if there is an appetite for this. I may have been wrong. nesting_level is used in both auto_explain and pg_stat_statements in contrib, and as mentioned by Lukas there are other extensions out in the ecosystem that do the same. I am not opposed to the idea of going down this path. I took a brief look today and found some missing nesting_level tests [0]. My initial thought is this would need some type of a backend stucture. I am not sure how attaching this to something like a queryDesc will be useful ( couldn't a single execution have multiple queryDesc? i.e nested queries, etc. ) [0] https://www.postgresql.org/message-id/CAA5RZ0uK1PSrgf52bWCtDpzaqbWt04o6ZA7zBm6UQyv7vyvf9w%40mail.gmail.com -- Sami Imseih Amazon Web Services (AWS)
