Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> (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
> 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


In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group