Re: pg_stat_statements

On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Wed, Jan 12, 2022 at 10:22:38AM +0000, Simon Riggs wrote:
> > On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud <rjuju123@gmail.com> wrote:
> > >
> > > Unfortunately this is a known limitation.
> >
> > I see this as a beneficial feature.
> >
> > If the same SQL is executed against different sets of tables, each
> > with different indexes, probably different data, the performance could
> > vary dramatically and might need different tuning on each. So having
> > separate rows in the pg_stat_statements output makes sense.
>
> Yes, having different rows seems like a good thing.  But being unable to tell
> which row apply to which schema is *not* a good thing.
>
> > > There were some previous discussions (e.g. [1] and [2] more recently), but I
> > > don't think there was a real consensus on how to solve that problem.
> >
> > To differentiate, run each schema using a different user, so you can
> > tell them apart.
>
> This isn't always possible.  For instance, once you reach enough schema it will
> be problematic to do proper pooling.

True, perhaps we should fix SET SESSION AUTHORIZATION to be allowed by
non-superusers. Then set the user and search_path at same time.

I was going to suggest adding a comment to the front of each SQL that
contains the schema, but that doesn't work either (and looks like a
bug, but how normalization works is not documented).

-- 
Simon Riggs                http://www.EnterpriseDB.com/