On 2025-Mar-25, Tom Lane wrote:
> Christoph Berg writes:
> > For 2), Tom said that configurability is 1) often much less useful
> > than originally planned, and 2) tools have to cope with both settings
> > anyway, making implementing them harder. Plus, switching at run-time
> > makes the result e
On 2025-Mar-25, Laurenz Albe wrote:
> On Tue, 2025-03-25 at 17:28 +0100, Christoph Berg wrote:
> > The "jumble names of temp tables" thread was briefly touching this [1],
> > I'm starting a new thread since the others are already very long.
> >
> > [1]
> > https://www.postgresql.org/message-id/f
On Tue, Mar 25, 2025, 7:40 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
>>> On Tue, Mar 25, 2025, 6:28 PM Álvaro Herrera
> wrote:
>
> On 2025-Mar-25, Tom Lane wrote:
>
> > If this GUC sticks around, it should be at least PGC_SUSET (on
>
> > the analogy of compute_query_id) to make it harder
On Tue, 2025-03-25 at 17:28 +0100, Christoph Berg wrote:
> The "jumble names of temp tables" thread was briefly touching this [1],
> I'm starting a new thread since the others are already very long.
>
> [1]
> https://www.postgresql.org/message-id/flat/CAA5RZ0uNofEXfEfNw3uRN3D3oXkFPQ_s%2BhuLLHMKR_
Re: Álvaro Herrera
> Introduce squashing of constant lists in query jumbling
>
> pg_stat_statements produces multiple entries for queries like
> SELECT something FROM table WHERE col IN (1, 2, 3, ...)
>
> depending on the number of parameters, because every element of
> ArrayExpr is individua
> At the same time the proposal to do squashing by default
> does not seem to be strictly dependent on that, so maybe they could be
> considered as isolated ideas.
Here is a patch to remove the GUC, if we settle on doing so.
--
Sami Imseih
Amazon Web Services (AWS)
v1-0001-Remove-the-query_id_s
> > If this GUC sticks around, it should be at least PGC_SUSET (on
> > the analogy of compute_query_id) to make it harder to break
> > pg_stat_statements that way.
>
> I have no problem making it superuser-only, and I can see making "on" be
> the default. I am not opposed to removing it completely
>
>
>> On Tue, Mar 25, 2025, 6:28 PM Álvaro Herrera
wrote:
On 2025-Mar-25, Tom Lane wrote:
> If this GUC sticks around, it should be at least PGC_SUSET (on
> the analogy of compute_query_id) to make it harder to break
> pg_stat_statements that way.
I have no problem making it superuser-only,
Christoph Berg writes:
> For 2), Tom said that configurability is 1) often much less useful
> than originally planned, and 2) tools have to cope with both settings
> anyway, making implementing them harder. Plus, switching at run-time
> makes the result even less predictable.
To clarify that last
