Re: pg_stat_statements query jumbling question

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