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. Testing quickly down to 14, this is the same behavior on all the branches up to HEAD. -- Michael
signature.asc
Description: PGP signature
