Re: Hash id in pg_stat_statements
От | Euler Taveira |
---|---|
Тема | Re: Hash id in pg_stat_statements |
Дата | |
Msg-id | 506B013A.1050601@timbira.com обсуждение исходный текст |
Ответ на | Re: Hash id in pg_stat_statements (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Hash id in pg_stat_statements
|
Список | 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, Suporte24x7 e Treinamento
В списке pgsql-hackers по дате отправления: