Re: query_id: jumble names of temp tables for better pg_stat_statement UX - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Date
Msg-id CAA5RZ0sQcnseBcE3VJDQ21wSA8h4khrNYPTMwb8r6Ki=yzkw7g@mail.gmail.com
Whole thread Raw
In response to Re: query_id: jumble names of temp tables for better pg_stat_statement UX  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> 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.

I ran installcheck-parallel with the patch and without the patch
3x, and the reduction in pg_s_s bloat is visible. The same entries
are reused even when the regression database is recreated, as
expected.

## without patch run installcheck-parallel 3 times
postgres=# select count(distinct queryid), count(*) from pg_stat_statements;
 count | count
-------+-------
 41630 | 74776
(1 row)


## with patch run installcheck-parallel 3 times
postgres=# select count(distinct queryid), count(*) from pg_stat_statements;
 count | count
-------+-------
 26301 | 73030
(1 row)

>This part of the thread is digressing, but I'd on the side of removing
> entirely the GUC and make the grouping of IN values the default.  We
> still have time to discuss that during the beta cycle, so let's do so
> on its related thread.

I will do that tomorrow in that thread. It would not make sense to introduce
a GUC for that behavior and not for this. So, I am glad we discussed this
here.

Looking at the patches, I could not find anything else besides what
was pointed out by Christoph earlier.

--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: AIO v2.5
Next
From: Tom Lane
Date:
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX