On 2015/09/01 14:39, Satoshi Nagayasu wrote:
> 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.
I know this still needs to be discussed, but I would like to submit
a patch for further discussion at the next CF, 2015-11.
Regards,
--
NAGAYASU Satoshi <snaga@uptime.jp>
