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
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 |