Re: pg_stat_statements

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Cc: "Dirschel, Steve" <steve(dot)dirschel(at)thomsonreuters(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_stat_statements
Date: 2022-01-12 10:31:41
Message-ID: 20220112103141.qf6dfobqbeezz5ls@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Amine Tengilimoglu 2022-01-12 11:16:34 How to read an external pdf file from postgres?
Previous Message Simon Riggs 2022-01-12 10:22:38 Re: pg_stat_statements