Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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>, 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-12 20:07:30
Message-ID: 3250173.1602533250@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Mon, Oct 12, 2020 at 02:26:15PM -0400, Tom Lane wrote:
>> Yeah, I agree --- a version number is the wrong way to think about this.

> The version number was to invalidate _all_ query hashes if the
> algorithm is slightly modified, rather than invalidating just some of
> them, which could lead to confusion.

Color me skeptical as to the use-case for that. From users' standpoints,
the hash is mainly going to change when we change the set of parse node
fields that get hashed. Which is going to happen at every major release
and no (or at least epsilon) minor releases. So I do not see a point in
tracking an algorithm version number as such. Seems like make-work.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-10-12 20:24:00 Re: SEARCH and CYCLE clauses
Previous Message Bruce Momjian 2020-10-12 19:54:43 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?