From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements query jumbling question |
Date: | 2015-09-01 05:01:16 |
Message-ID: | 25151.1441083676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Satoshi Nagayasu <snaga(at)uptime(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-09-01 05:08:20 | Re: [PATCH] SQL function to report log message |
Previous Message | Pavel Stehule | 2015-09-01 04:59:12 | Re: [PATCH] SQL function to report log message |