On 2015/09/01 14:01, Tom Lane wrote:
> 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.
I'm not confident about that too, but at least, I think we will be able
to collect most common use cases as of today. (aka best guess. :)
And IMHO it would be ok to change the spec in future release.
Regards,
--
NAGAYASU Satoshi <snaga@uptime.jp>
