Re: pg_stat_statements query jumbling question - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_stat_statements query jumbling question
Date
Msg-id 5634F47E.8040104@dalibo.com
Whole thread Raw
In response to Re: pg_stat_statements query jumbling question  (Satoshi Nagayasu <snaga@uptime.jp>)
Responses Re: pg_stat_statements query jumbling question  (Peter Geoghegan <pg@heroku.com>)
Re: pg_stat_statements query jumbling question  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On 10/10/2015 08:46, Satoshi Nagayasu wrote:
> On 2015/10/03 6:18, Peter Geoghegan wrote:
>> On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu
>> <snaga@uptime.jp> wrote:
>>> I know this still needs to be discussed, but I would like to
>>> submit a patch for further discussion at the next CF, 2015-11.
>> 
>> I think I already expressed this in my explanation of the
>> current behavior, but to be clear: -1 from me to this proposal.
> 
> I would like to introduce queryId to pgaudit and sql_firewall
> extensions to determine query groups. queryId could be useful if
> available in those modules.
> 
> I think users may want to do that based on object names, because
> they issue queries with the object names, not the internal object
> ids.
> 
> Changing queryId after re-creating the same table may make the
> user gets confused, because the query string the user issue is not
> changed.
> 
> At least, I would like to give some options to be chosen by the
> user. Is it possible and/or reasonable?
> 

I'm also rather sceptical about this change.

In any case, the change you propose in this patch is not good, as you
only consider the relation name and ignore the relation's schema. You
need to also add the namespace name in the jumble state.

Also, the documentation would need to be updated, at least on this part:

"As a rule of thumb, queryid values can be assumed to be stable and
comparable only so long as the underlying server version and catalog
metadata details stay exactly the same. Two servers participating in
replication based on physical WAL replay can be expected to have
identical queryid values for the same query. However, logical
replication schemes do not promise to keep replicas identical in all
relevant details, so queryid will not be a useful identifier for
accumulating costs across a set of logical replicas. If in doubt,
direct testing is recommended."

Regards.

> Regards,


- -- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBAgAGBQJWNPR+AAoJELGaJ8vfEpOqP3AH/j8Eob8jaXnhXNGsjJ7NyBkc
91pn87iW+FgyRGNH8K7wvOyPnBl3JWjlaIVShdImoph6agn6HhyXqbEceKXKKBS5
7B2fhY0xjhzFrKbQ9NpwxAvnPKA4ChOFsFmN/YtJMZzBEUHMDBcZpixhoGXy6iKB
Q44blhmZswXtJ744p3oslUNJX0eKoIZuqxRihVvUJYo/7Ogh0kWje5W4btA+CT/k
/IkQcMgUZj8jhyNYqBTaxlgNRJvTmk+iSuieAL6Fjjwq/VhR9QyD+4viKC+q0Nf6
puL74qPvwLzvy3+MXGc0dg+8m+PwZWcDg/pZSka+5EwJaHUv5bjouDZqimHH978=
=jlQP
-----END PGP SIGNATURE-----



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: snapshots in analyze
Next
From: Marko Tiikkaja
Date:
Subject: COPY (INSERT/UPDATE/DELETE .. RETURNING ..)