Re: pg_stat_statements

On Wed, 12 Jan 2022 at 13:17, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
> On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud <rjuju123(at)gmail(dot)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(at)gmail(dot)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.

But SET ROLE works.

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