On 24 May 2012 16:06, Tom Lane <tgl@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 ...
>
>>> ... I'd also credit our users with being
>>> discerning enough to realise that they should not jump to the
>>> conclusion that the value will be stable according to any particular
>>> standard.
>
> ... is in direct contradiction to this.
I simply meant that we ought to be able to trust that people will
actually investigate the stability guarantees of a newly exposed
query_id before going and writing a tool that does some sort of
aggregation - they should and will make informed decisions. If that
guarantee is limited to "we might have to change the walker logic
during a minor release, so the value might change for some queries, so
we don't promise that it will be a stable identifier but will
naturally strive to do our best to avoid invalidating existing
statistics (within postgres and aggregated by external tools)", that
wouldn't put many people off. Still, I don't think it's all that
likely that we'll ever have to adjust the walker logic, since
pg_stat_statements already doesn't strictly promise that collisions
cannot occur, while making them very improbable.
I'm not even asking that possible uses for queryId be documented as
being useful for this sort of thing. I only ask that we expose it and
document it.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services