Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id CAFj8pRBiBsReXskjmU6c-+HHS2Q5=7eB9JJJDXvVbUZnR+FmFA@mail.gmail.com
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers


st 12. 5. 2021 v 8:10 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
On Wed, May 12, 2021 at 07:49:13AM +0200, Pavel Stehule wrote:
>
> > Ah, I missed that case.  And we are wanting to use pg_stat_statements
> > with (almost) zero-config?  How about the following behavior?
> >
> >
> Until now, the pg_stat_statements was zero-config. So the change is not
> user friendly.

Apart from configuring shared_preload_libraries, but agreed.

> The idea so pg_stat_statements requires enabled computed_query_id is not
> good. There should be dependency only on the queryid column.

I agree that requiring to change compute_query_id when you already added
pg_stat_statements in shared_preload_libraries isn't good, and the patch I sent
yesterday would fix that.

I don't like the idea of implicit force enabling any feature flag, but it is better than current design. But it doesn't look like a robust solution.

Does it mean that if somebody disables computed_query_id, then pg_stat_statements will not work?

Why is there the strong dependency between computed_query_id and pg_stat_statements? Can this dependency be just optional?

Regards

Pavel

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: PG 14 release notes, first draft
Next
From: Amit Langote
Date:
Subject: Re: PG 14 release notes, first draft