On Thu, May 24, 2012 at 5:20 PM, Peter Geoghegan wrote:
> On 24 May 2012 16:06, Tom Lane wrote:
>> I do not want to promise that it's stable over any timeframe longer than
>> a server reboot.
>
> You already have though, since pg_stat_statements persistently stores
> statistics to disk by default
On 24 May 2012 16:06, Tom Lane wrote:
>>> What I'd like to be able to do is aggregate this information over time
>>> and/or across standbys in a cluster, as queries are evicted and
>>> subsequently re-entered into pg_stat_statement's shared hash table.
>
> It appears to me that the above ...
>
>>>
On 24 May 2012 16:06, Tom Lane wrote:
> I do not want to promise that it's stable over any timeframe longer than
> a server reboot.
You already have though, since pg_stat_statements persistently stores
statistics to disk by default, and can only ever recognise statement
equivalence based on the (
Robert Haas writes:
> On Thu, May 24, 2012 at 10:26 AM, Peter Geoghegan
> wrote:
> But I think this explanation is enough to convince me that it might be
> worthwhile:
>> What I'd like to be able to do is aggregate this information over time
>> and/or across standbys in a cluster, as queries ar
On Thu, May 24, 2012 at 10:26 AM, Peter Geoghegan wrote:
> On 24 May 2012 11:50, Magnus Hagander wrote:
>> Was there any actual reason why we didn't end up exposing queryid in
>> the pg_stat_statements view?
>>
>> It would be highly useful when tracking changes over time. Right now I
>> see peopl
On Thu, May 24, 2012 at 4:26 PM, Peter Geoghegan wrote:
> On 24 May 2012 11:50, Magnus Hagander wrote:
>> Was there any actual reason why we didn't end up exposing queryid in
>> the pg_stat_statements view?
>>
>> It would be highly useful when tracking changes over time. Right now I
>> see people
On 24 May 2012 11:50, Magnus Hagander wrote:
> Was there any actual reason why we didn't end up exposing queryid in
> the pg_stat_statements view?
>
> It would be highly useful when tracking changes over time. Right now I
> see people doing md5(query) to do that, which is a lot more ugly (and
> ob
Was there any actual reason why we didn't end up exposing queryid in
the pg_stat_statements view?
It would be highly useful when tracking changes over time. Right now I
see people doing md5(query) to do that, which is a lot more ugly (and
obviously uses more space and is slow, too).
--
Magnus H
