P On Oct 2, 2012 5:04 PM, "Euler Taveira" <eu...@timbira.com> wrote: > > On 02-10-2012 10:15, Peter Geoghegan wrote: > > There are other, similar tools that exist in proprietary databases. > > They expose a hash value, which is subject to exactly the same caveats > > as our own. They explicitly encourage the type of aggregation by > > third-party tools that I anticipate will happen with > > pg_stat_statements. I want to facilitate this, but I'm confident that > > the use of (dbid, userid, querytext) as a "candidate key" by these > > tools is going to cause confusion, in subtle ways. By using the hash > > value, those tools are exactly as well off as pg_stat_statements is, > > which is to say, as well off as possible. > > > It depends on how you will use this information. If it is for a rapid > analysis, it is fine to use a hash because the object internals won't change > (I hope not). However, if you want to analyze query statistics for a long > period of time (say a few months) or your environment is distributed, you > can't use the hash. There isn't a perfect solution but I see both cases being > useful for analysis tools.
Having the hash available in no way prevents you from using the query string ad your key. Not having the hash certainly prevents you from using it. /Magnus
