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: 506B013A.1050601@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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 http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

In response to

Responses

Browse pgsql-hackers by date

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