| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Evgeny Efimkin <efimkin(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
| Date: | 2020-10-07 01:42:49 |
| Message-ID: | 20201007014249.GB2256@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 06, 2020 at 09:22:29AM -0400, Bruce Momjian wrote:
> I propose moving the pg_stat_statements queryid hash code into the
> server (with a version number), and also adding a postgresql.conf
> variable that lets you control how detailed the queryid hash is
> computed. This addresses the problem of people wanting different hash
> methods.
In terms of making this part expendable in the future, there could be
a point in having an enum here, but are we sure that we will have a
need for that in the future? What I get from this discussion is that
we want a unique source of truth that users can consume, and that the
only source of truth proposed is the PGSS hashing. We may change the
way we compute the query ID in the future, for example if it gets
expanded to some utility statements, etc. But that would be
controlled by the version number in the hash, not the GUC itself.
> When computing a hash, the queryid detail level and version number will
> be mixed into the hash, so only a hash that used a similar query and
> identical queryid detail level would match.
Yes, having a version number directly dependent on the hashing sounds
like a good compromise to me.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-10-07 01:45:07 | Re: Prevent printing "next step instructions" in initdb and pg_upgrade |
| Previous Message | Tomas Vondra | 2020-10-07 00:58:38 | Re: WIP: WAL prefetch (another approach) |