Re: pg_stat_statements query jumbling question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_statements query jumbling question
Date
Msg-id 25151.1441083676@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_statements query jumbling question  (Satoshi Nagayasu <snaga@uptime.jp>)
Responses Re: pg_stat_statements query jumbling question  (Satoshi Nagayasu <snaga@uptime.jp>)
List pgsql-hackers
Satoshi Nagayasu <snaga@uptime.jp> writes:
> On 2015/09/01 13:41, Peter Geoghegan wrote:
>> If you want to use the queryId field directly, which I recall you
>> mentioning before, then that's harder. There is simply no contract
>> among extensions for "owning" a queryId. But when the fingerprinting
>> code is moved into core, then I think at that point queryId may cease
>> to be even a thing that pg_stat_statements theoretically has the right
>> to write into. Rather, it just asks the core system to do the
>> fingerprinting, and finds it within queryId. At the same time, other
>> extensions may do the same, and don't need to care about each other.
>> 
>> Does that work for you?

> Yes. I think so.

> I need some query fingerprint to determine query group. I want queryid
> to keep the same value when query strings are the same (except literal 
> values).

The problem I've got with this is the unquestioned assumption that every
application for query IDs will have exactly the same requirements for
what the ID should include or ignore.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [PATCH] SQL function to report log message
Next
From: Pavel Stehule
Date:
Subject: Re: [PATCH] SQL function to report log message