On Mon, Dec 23, 2024 at 11:01 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Dec 23, 2024 at 10:06:58PM -0600, Merlin Moncure wrote: > I'm aware of that and will set it -- it's the only option if I'm following > you. The way I've been doing things lately for bulk processing is a lot > of orchestrated procedures that are organized for purposes of monitoring > and easy administration, and telemetry would tend to be at that level, but > more granular tracking will get the job done and ought to be perfectly fine > as long as overhead is reasonable. > > Mainly, I was curious if the behavior not to parse constants out of stored > procedure invocations was an unintentional artifact of the > utility statement approach. I guess it might be, but also that there is > nothing to solve here.
Hmm. So you mean that a combination of track_utility = off and track = 'all' leads to the internals of CALL to not be normalized on first call, while if we have track_utility = on and track = 'all' then the internals of CALL are normalized. The behavior is different depending on if the procedure is cached or not, as well, the second call following the traces of the first call and we ignore the combinations of the two GUCs. This kind of inconsistency is what I would call a bug. I'm pretty sure that it is saner to say that we should apply normalization all the time if we can, not avoid normalization in some cases like the one you are pointing at.
Actually, I hadn't gotten that far yet; I was just noticing that:
CALL foo(1,2,3);
CALL foo(2,3,4);
...resolved to different queryids and if that was expected, and if not, if some logic tune-ups in the extension improve behavior without deeper changes.
With client side preparation, you can work around this (e.g. CALL foo($1, $2)) but it's impossible from any non-paramaterizing client or the server (for top level) since explicit prepared statements are not allowed for stored procedures -- that's pretty limiting IMNSHO.
If there are issues with the non-top level approach -- that makes it worse. For my part, I'm going to tweak the extension to see if there's any relief there. Thanks for taking a look.
