On 2015/09/01 13:41, Peter Geoghegan wrote:
> On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu <snaga@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 <snaga@uptime.jp>
