On Thu, May 24, 2012 at 5:20 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 24 May 2012 16:06, Tom Lane t...@sss.pgh.pa.us 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
On 24 May 2012 11:50, Magnus Hagander mag...@hagander.net 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
On Thu, May 24, 2012 at 4:26 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 24 May 2012 11:50, Magnus Hagander mag...@hagander.net 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
On Thu, May 24, 2012 at 10:26 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 24 May 2012 11:50, Magnus Hagander mag...@hagander.net 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
Robert Haas robertmh...@gmail.com writes:
On Thu, May 24, 2012 at 10:26 AM, Peter Geoghegan pe...@2ndquadrant.com
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
On 24 May 2012 16:06, Tom Lane t...@sss.pgh.pa.us 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
On 24 May 2012 16:06, Tom Lane t...@sss.pgh.pa.us 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
