Subject: Re: Feature improvement: can we add queryId for
 pg_catalog.pg_stat_activity view?
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yun Li <liyunjuanyong@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CA+8PKvQnMfOE-c3YLRwxOsCYXQDyP8VXs6CDtMZp1V4=D4LuFA@mail.gmail.com>
 <21800.1552701008@sss.pgh.pa.us>
 <CA+TgmobNUwzTnb6f5Kmw=qSXXs2sMexerd8uTyaHE2CG9=F=SQ@mail.gmail.com>
From: Maksim Milyutin <milyutinma@gmail.com>
Message-ID: <e26f1ee3-ff22-f871-2348-b04dbc98ec3e@gmail.com>
Date: Tue, 19 Mar 2019 16:45:17 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmobNUwzTnb6f5Kmw=qSXXs2sMexerd8uTyaHE2CG9=F=SQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 3/16/19 5:32 PM, Robert Haas wrote:

> There's only one query ID field available, and
> you can't use two extensions that care about query ID unless they
> compute it the same way, and replicating all the code that computes
> the query ID into each new extension that wants one sucks.  I think we
> should actually bite the bullet and move all of that code into core,
> and then just let extensions say whether they care about it getting
> set.


+1.

But I think that enough to integrate into core the query normalization 
routine and store generalized query strings (from which the queryId is 
produced) in shared memory (for example, hashtable that maps queryId to 
the text representation of generalized query). And activate 
normalization routine and filling the table of generalized queries by 
specified GUC.

This allows to unbind extensions that require queryId from using 
pg_stat_statements and consider such computing of queryId as canonical.


-- 
Regards,
Maksim Milyutin