Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, torikoshia <torikoshia@oss.nttdata.com>,
Atsushi Torikoshi <atorik@gmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Evgeny Efimkin <efimkin@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-07T17:07:19Z
Lists: pgsql-hackers
Attachments
- v15-0003-Expose-query-identifier-in-verbose-explain.patch (text/x-patch) patch v15-0003
- v15-0001-Move-pg_stat_statements-query-jumbling-to-core.patch (text/x-patch) patch v15-0001
- v15-0002-Expose-queryid-in-pg_stat_activity-and-log_line_.patch (text/x-patch) patch v15-0002
On Sun, Oct 18, 2020 at 4:12 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > > On Sun, Oct 18, 2020 at 12:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > > Wait ... what? I've been thinking that this GUC is just to enable or > > > disable the computation of query ID, not to change the algorithm to do > > > so. Do we really need to allow different algorithms in different > > > sessions? > > > > We established that some time ago, no? > > I thought we established the need for allowing different algorithms, > but I assumed globally not per session. Anyway, allowing to enable or > disable compute_queryid per session would technically allow that, > assuming that you have another module loaded that computes a queryid > only if no-one was already computed. In that case pg_stat_statements > works as you would expect, you will get a new entry, with a duplicated > query text. > > With a bit more thinking, there's at least one use case where it's > interesting to disable pg_stat_statements: queries using temporary > tables. In that case you're guaranteed to generate an infinity of > different queryid. That doesn't really help since you're not > aggregating anything anymore, and it also makes pg_stat_statements > virtually unusable as once you have a workload that needs frequent > eviction, the overhead is so bad that you basically have to disable > pg_stat_statements. We could alternatively add a GUC to disable > queryid computation when one of the tables is a temporary table, but > that's yet one among many considerations that are probably best > answered with a custom implementation. > > I'm also attaching an updated patch with some attempt to improve the > documentation. I mention that in-core algorithm may not suits > everyone's needs, but we don't actually document what heuristics are. > Should we give more details on them and what are the most direct > consequences? v15 that fixes recent conflicts.
Commits
-
Clarify description of pg_stat_statements columns
- b4deefc39b93 15.0 landed
- 3b57d5af7435 14.0 landed
-
Fix wording in description of pg_stat_statements.toplevel
- f9e6d00df029 14.0 landed
-
Mention that toplevel is part of pg_stat_statements key.
- 7531fcb1fcf5 14.0 landed
-
adjust query id feature to use pg_stat_activity.query_id
- 9660834dd8bf 14.0 landed
-
Update copyright for 2021
- ca3b37487be3 14.0 cited
-
Take the statistics collector out of the loop for monitoring backends'
- b13c9686d084 8.2.0 cited