Re: stored procedures vs pg_stat_statements

On Mon, Dec 23, 2024 at 3:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> > Can this simply be disabled for stored procedures as a special case? I'm
> > hoping this might do something useful that is also safe. Curious if
> anyone
> > has any thoughts on this.
>
> No, I don't think that would help. The restriction on utility
> statements would cover CREATE PROCEDURE/FUNCTION, not calls
> of those things which is what I suppose you care about.
>
> Do you have pg_stat_statements.track set to "all"? That should
> allow statements within stored procedures to be tracked, which
> again is what I'm guessing you care about.
>

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. Thanks for taking the time to respond.

merlin