Re: Hash id in pg_stat_statements

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Euler Taveira <euler(at)timbira(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Hash id in pg_stat_statements
Date: 2012-10-02 15:08:54
Message-ID: CABUevExRjvZkdnTtkS-jjLWzeFaDBByer+tajUZ3hWRDjEc7oQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

P
On Oct 2, 2012 5:04 PM, "Euler Taveira" <euler(at)timbira(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-10-02 15:46:37 Re: Doc patch to note which system catalogs have oids
Previous Message Euler Taveira 2012-10-02 14:59:06 Re: Hash id in pg_stat_statements