On 2015/09/01 13:41, Peter Geoghegan wrote:
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.
Yes. I've been working on the sql_firewall extension[1], which is
totally built on top of the pg_stat_statements.
[1] http://pgsnaga.blogspot.jp/2015/08/postgresql-sql-firewall.html
As of today, sql_firewall has duplicated code for query jumbling.
But if it goes into the core, it looks fantastic.
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.
Sounds cool. :)
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).
Another reason is just because I need to import/export query ids.
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
