On 2015/09/01 14:01, Tom Lane wrote: > Satoshi Nagayasu <sn...@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 <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
