On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud <rjuju123@xxxxxxxxx> 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@xxxxxxxxx> 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/
