On Thu, May 24, 2012 at 4:26 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > On 24 May 2012 11:50, Magnus Hagander <mag...@hagander.net> wrote: >> Was there any actual reason why we didn't end up exposing queryid in >> the pg_stat_statements view? >> >> It would be highly useful when tracking changes over time. Right now I >> see people doing md5(query) to do that, which is a lot more ugly (and >> obviously uses more space and is slow, too). > > Right. I continue to maintain that this is a good idea. I raised the > issue more than once. However, my proposal was not accepted by Tom and > Robert, apparently on the basis that queryId's actual value was > partially dictated by things like the endianness of the architecture > used, and the value of OIDs when serialising and subsequently hashing > the post-analysis tree. > > What I'd like to be able to do is aggregate this information over time > and/or across standbys in a cluster, as queries are evicted and > subsequently re-entered into pg_stat_statement's shared hash table.
That's exactly the usecase I'm looking at here, except it's not actually across standbys in this case. > Now, there are situations were this isn't going to work, like when a > third-party logical replication system is used. That's unfortunate, > but I wouldn't expect it makes the information any less useful to the > large majority of people. I'd also credit our users with being > discerning enough to realise that they should not jump to the > conclusion that the value will be stable according to any particular > standard. As long as it's documented as such, I don't see a problem with that at all. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
