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