MIME-Version: 1.0
References: <Z96GJEmTnvHKz_Kn@msg.df7cb.de> <Z96Rz-4IEyRCS4ny@paquier.xyz>
 <1831838.1742656359@sss.pgh.pa.us> <80506.1742660683@sss.pgh.pa.us>
 <Z99aIy9T0f-lulK5@paquier.xyz> <461405.1742691859@sss.pgh.pa.us>
 <Z9-sUvq8pE5uinEu@paquier.xyz> <CAA5RZ0t4XQ_SANiJ5VfuoKnAuxMaY2ggQWoGKkHo+U2H+Sh-Sw@mail.gmail.com>
 <1189112.1742869660@sss.pgh.pa.us> <CAA5RZ0uNofEXfEfNw3uRN3D3oXkFPQ_s+huLLHMKR_+MCk8RPQ@mail.gmail.com>
 <Z-IoMKL8I-r-xsuW@paquier.xyz>
In-Reply-To: <Z-IoMKL8I-r-xsuW@paquier.xyz>
From: Lukas Fittl <lukas@fittl.com>
Date: Mon, 24 Mar 2025 23:09:06 -0700
Message-ID: <CAP53PkzAPrHNHquT76mVjfStrz0B2hKhF+CbAZ_w9QJUJ_1oJQ@mail.gmail.com>
Subject: Re: query_id: jumble names of temp tables for better
 pg_stat_statement UX
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, 
	ma lz <ma100@hotmail.com>
Content-Type: multipart/alternative; boundary="0000000000001e75ab06312491ac"
Archived-At: <https://www.postgresql.org/message-id/CAP53PkzAPrHNHquT76mVjfStrz0B2hKhF%2BCbAZ_w9QJUJ_1oJQ%40mail.gmail.com>
Precedence: bulk

--0000000000001e75ab06312491ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 24, 2025 at 8:51=E2=80=AFPM Michael Paquier <michael@paquier.xy=
z> wrote:

> On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > > select * from foo s1;
> > > select * from foo s2;
> >
> > ah, thanks for pointing this out. Not as good of a workaround as
> > a comment since one must change aliases, but at least there is
> > a workaround...
>
> Exactly.  Like Tom I'm not really worried about the proposal, but of
> course I could prove to be wrong.  I am ready to assume that bloat in
> pgss entries caused by temp tables is a more common case.
>

For what its worth, +1 on the current proposal in this thread (and doing it
without a GUC), i.e. merging a query that references the same table alias,
ignoring different schemas.

In the context of the earlier referenced one-schema-per-customer workloads:

In my experience these often not work well with pg_stat_statements today
because of their own bloat problem, just like with temp tables. You quickly
have way too many unique entries, and your query text file accumulates a
lot of duplicative entries (since the same query text gets repeated in the
text file, since its queryid is different), to the point that you can't
monitor your workload at all anymore.

Thanks,
Lukas

--=20
Lukas Fittl

--0000000000001e75ab06312491ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 24, 2025 at =
8:51=E2=80=AFPM Michael Paquier &lt;<a href=3D"mailto:michael@paquier.xyz" =
target=3D"_blank">michael@paquier.xyz</a>&gt; wrote:</div><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 24,=
 2025 at 09:38:35PM -0500, Sami Imseih wrote:<br>
&gt; &gt; select * from foo s1;<br>
&gt; &gt; select * from foo s2;<br>
&gt; <br>
&gt; ah, thanks for pointing this out. Not as good of a workaround as<br>
&gt; a comment since one must change aliases, but at least there is<br>
&gt; a workaround...<br>
<br>
Exactly.=C2=A0 Like Tom I&#39;m not really worried about the proposal, but =
of<br>
course I could prove to be wrong.=C2=A0 I am ready to assume that bloat in<=
br>
pgss entries caused by temp tables is a more common case.<br></blockquote><=
div><br></div><div><div>For what its worth, +1 on the current proposal in t=
his thread (and doing it without a GUC), i.e. merging a query that referenc=
es the same table alias, ignoring different schemas.</div><div><div><br></d=
iv><div>In the context of the earlier referenced one-schema-per-customer=20
workloads:</div><div><br></div><div>In my experience these often not work w=
ell with pg_stat_statements today because of their own bloat problem, just =
like with temp tables. You=20
quickly have way too many unique entries, and your query text file=20
accumulates a lot of duplicative entries (since the same query text gets
 repeated in the text file, since its queryid is different), to the point t=
hat you can&#39;t monitor your workload at all anymore.</div><div><br></div=
><div>Thanks,</div><div>Lukas</div></div><br></div></div><span class=3D"gma=
il_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr">Lukas Fittl=
</div></div></div></div></div></div></div>
</div>

--0000000000001e75ab06312491ac--