On Wed, 12 Jan 2022 at 13:17, Simon Riggs <simon.ri...@enterprisedb.com> wrote: > > On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud <rjuju...@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 <rjuju...@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.
But SET ROLE works. -- Simon Riggs http://www.EnterpriseDB.com/
