Re: pg_stat_statements - Mailing list pgsql-general

From Julien Rouhaud
Subject Re: pg_stat_statements
Date
Msg-id 20220112103141.qf6dfobqbeezz5ls@jrouhaud
Whole thread Raw
In response to Re: pg_stat_statements  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: pg_stat_statements  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-general
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.



pgsql-general by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_stat_statements
Next
From: Amine Tengilimoglu
Date:
Subject: How to read an external pdf file from postgres?