Re: Hash id in pg_stat_statements - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Hash id in pg_stat_statements
Date
Msg-id CAEYLb_UczVJFcQzdzoMr4W=19zMTXC4_tXzjD5JA1RmJstDjbA@mail.gmail.com
Whole thread Raw
In response to Re: Hash id in pg_stat_statements  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
On 3 October 2012 19:54, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 3 October 2012 19:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This argument seems sensible to me.  Is there any use-case where the
>> proposed counter wouldn't do what people wished to do with an exposed
>> hash value?
>
> Yes. The hash could be used to aggregate query execution costs across
> entire WAL-based replication clusters. I'm not opposed to Daniel's
> suggestion, though.

I failed to mention a more compelling use-case. On systems that use
roles extensively, there will naturally from time to time be a desire
to see things at the query granularity, rather than at the (userid,
queryid) granularity. Exposing the hash value allows the user to
construct an aggregate query that groups by the hash value, rather
than the query string. For all the reasons already mentioned, this is
a better principled approach than using the query string.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Hash id in pg_stat_statements
Next
From: Hannu Krosing
Date:
Subject: Is there a good reason why PL languages do not support cstring type arguments and return values ?