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
Re: pg_stat_statements query jumbling question |
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: