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

Re: Hash id in pg_stat_statements

From: Euler Taveira <euler(at)timbira(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash id in pg_stat_statements
Date: 2012-10-02 14:59:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

   Euler Taveira de Oliveira - Timbira
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-10-02 15:08:54
Subject: Re: Hash id in pg_stat_statements
Previous:From: Phil SorberDate: 2012-10-02 14:47:27
Subject: Missing OID define

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