On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote: > BTW, I'm interested in improving the queryid portability now because > I'd like to use it in other extensions. :) > That's the reason why I'm looking at query jumbling here.
Are you interested in having the query fingerprinting/jumbling infrastructure available to all backend code? That seems like a good idea to me generally. I would like to be able to put queryId in log_line_prefix, or to display it within EXPLAIN, and have it available everywhere. I like the idea of per-query log_min_duration_statement settings. 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? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers