Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tx9CI-003eAn-U5 for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 18:40:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tx9CF-00883q-Un for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 18:40:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <9erthalion6@gmail.com>) id 1tx9CF-00883i-Ja for pgsql-hackers@lists.postgresql.org; Tue, 25 Mar 2025 18:40:19 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <9erthalion6@gmail.com>) id 1tx9CD-001890-17 for pgsql-hackers@lists.postgresql.org; Tue, 25 Mar 2025 18:40:19 +0000 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-39127512371so4032110f8f.0 for ; Tue, 25 Mar 2025 11:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742928014; x=1743532814; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=svyM1yKMwvOjfImjHh9vgFjDPZ2aQjDLUEIkEp8IZm0=; b=facvKCh3G/kV0vWm11sK4JmOyBcliSvfkfI+amVmYJ4yp0Jn9s1zxh9hnT0XznrPYu w7F59zqm2bU94xbnLi/uXAi4ZbE8/4jHTigk/u4Lw75/ltwyZg2WomlaibojbWCON+hN Ofhs3yNIF9uScGaV3/9k9uY1ejB6Cj53nNiOPPHkXL3taP54c1ns0XbctOVyQ2oW8hCv LJMAXZqldU8lzriLp+IMYeF0CDHOZZHgia/xRxXyJU3TYz4TxWJTFbOmXPQI79+2SYfZ rhjKP/5XwnQySUM1BO2vA4ukHOhwxT29B58MT+sNIAZtScIPM+2Sk/xiRkPJ1DYxVYT7 XXPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742928014; x=1743532814; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=svyM1yKMwvOjfImjHh9vgFjDPZ2aQjDLUEIkEp8IZm0=; b=i6HONcvnnzSJk0BhnsjQWJwzuU2mEarT6lsDIUdQeJ+ulaEw/BTAtzqHMld4Y+Gy+6 2F+sObVL+6jvihA0vpDMBpNBJNWo4p43j+kMIWmXITtfp0O+Lvg+NJyDLIbEoN/sLz5W UmxoXRZNTejjr4g/razrqUjUq0uBljGlU/KerQSjEZcw95Iznb/LI6bOt9sWVsgbJSEm pYMBrO5IYnYkBv6LUmIIgxtnkqn1tyCPDE1S8eXNEc+ivocDiOb2ii5ymSQdtDZzg9Ge JfwG7ZmrcC3O65W+aZv69w+dEYGE5v3rkuiQiZX/DF52TCZa4qqAd4KUbpIm7UFPP8bl ao1Q== X-Forwarded-Encrypted: i=1; AJvYcCV1Nycf5EssS+nq7HVu42jgPTsVIUmKGNqkylwB8jfkMo+nA+w6A1kNDeiI/OiIdRP1ZyWV+oK7GLFxWTKS@lists.postgresql.org X-Gm-Message-State: AOJu0YyBMjKsK67EE2Yv0VGV/7BqXyLJJmrCg1u1j/xlvYREGUeNj3ZK bv92c0PzT+couQwLSiw0pT2Gak+2sZ2T0dA3ogy/tcdM6EVAoTP2UYzySm0s1dxVuNu/Z9ZYaZG 9jQ9D27j2iPSoRxZoJ95bct+QdNk= X-Gm-Gg: ASbGnct/LDKtAlwjgsD7Va2ToPSjgrc9jLHsH2PPmKAg/7VDAXGHfk8ogoFTzUaIgXX ubgm8esBagqI2eIwyk1PG1cSkJbZEZubjOb6rqCsyHJDRz/YTt00iw9GHHgf1hdh32GQkFeWz88 63VP+SWvHYJmTtTBryPTBamDN5XA== X-Google-Smtp-Source: AGHT+IGyiyyIYcRxctbvPUqQck+HY0iOBu5zCZ9WIOGNRhiiG2qlweCCSarR6E8vIugdXfXzwLB8b4McMYrYDbgLIlY= X-Received: by 2002:a5d:6c61:0:b0:390:f902:f973 with SMTP id ffacd0b85a97d-3997f8f5c08mr16729908f8f.8.1742928014289; Tue, 25 Mar 2025 11:40:14 -0700 (PDT) MIME-Version: 1.0 References: <1282250.1742921593@sss.pgh.pa.us> <202503251727.pn3eg43zqkdk@alvherre.pgsql> In-Reply-To: <202503251727.pn3eg43zqkdk@alvherre.pgsql> From: Dmitry Dolgov <9erthalion6@gmail.com> Date: Tue, 25 Mar 2025 19:40:01 +0100 X-Gm-Features: AQ5f1Jr1zYMT4Ce2E8esctQluM8_LfBHskTBJbH512JaOWSCn9n0YEsTL-JJm4A Message-ID: Subject: Re: Squash constant lists in query jumbling by default To: =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: Tom Lane , Christoph Berg , PostgreSQL Developers , Sami Imseih , Michael Paquier , Julien Rouhaud Content-Type: multipart/alternative; boundary="0000000000002934ab06312f0db0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002934ab06312f0db0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > >> On Tue, Mar 25, 2025, 6:28 PM =C3=81lvaro 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, and I can see making "on" be the default. I am not opposed to removing it completely either, if we really think that the current behavior is no longer useful for anybody. I'm in favor of removing the GUC of course, but if memory serves there were some folks in the patch discussion thread, who claimed they would need to be able to keep non-squashed behavior. I don't recall if there were particular arguments to support that, will try to find those messages again= . But overall as long as nobody objects, I think it's fine to get rid of GUC. Earlier in the discussion, other possible values for the option were suggested, such as a way to distinguish arrays that had "lots" (say, hundreds or more) of entries from arrays that were "small". That could be selected by the user (or site admin) using this GUC, though there was no agreement on exactly what that would be. During the FOSDEM 2024 development meeting there was a general dislike of this idea, which AFAIR was mostly predicated on the displayed query no longer being valid SQL. But now that we've chosen a format that uses SQL comments, this is no longer a problem, so I think we haven't closed that door yet. But we may still find out that no user cares about this. Agree, the way how things work now brings this option back on the table. I can refresh the patch doing this, but I'm afk for about a week so it will take some time. 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. > --0000000000002934ab06312f0db0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= /blockquote>

On Tue, M= ar 25, 2025, 6:28 PM =C3=81lvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2025-Mar-25, Tom Lane wrote:
> If this GUC sticks aroun= d, it should be at least PGC_SUSET (on
> the analogy of compute_query_id) to make it harder= to break
> pg_s= tat_statements that way.

I have n= o problem making it superuser-only, and I can see making "on" be<= /blockquote>
the default.=C2=A0 = I am not opposed to removing it completely either, if we
really think that the current behavio= r is no longer useful for=C2=A0anybody.

I'm in favor of removing the GUC of course= , but if memory serves there
were some folks in the = patch discussion thread, who claimed they would
need= to be able to keep non-squashed behavior. I don't recall if there were=
particular arguments to support that, will try to f= ind those messages again.
But overall as long as nob= ody objects, I think it's fine to get rid of GUC.

E= arlier in the discussion, other possible values for the option were
sugg= ested, such as a way to distinguish arrays that had "lots" (say,<= br>hundreds or more) of entries from arrays that were "small".=C2= =A0 That could
be selected by the user (or site admin) using this GUC, t= hough there was
no agreement on exactly what that would be.=C2=A0 During= the FOSDEM 2024
development meeting there was a general dislike of this= idea, which
AFAIR was mostly predicated on the displayed query no longe= r being valid
SQL.=C2=A0 But now that we've chosen a format that use= s SQL comments, this is
no longer a problem, so I think we haven't c= losed that door yet.=C2=A0 But we
may still find out that no user cares = about this.
Agree, the way how things work now brings this opt= ion back on the table.
I can refresh the patch doing= this, but I'm afk for about a week so it will
t= ake some time. At the same time the proposal to do squashing by default
does not seem to be strictly dependent on that, so mayb= e they could be
considered as isolated ideas.
<= div class=3D"gmail_quote gmail_quote_container" dir=3D"auto">
--0000000000002934ab06312f0db0--