On 1 October 2012 17:12, Stephen Frost <[email protected]> wrote: > Peter, all, > > * Peter Geoghegan ([email protected]) wrote: >> Well, I'll point out once again that the argument about its stability >> is invalid, because we serialise the entries to disk. If a point >> release changes the representation of the query tree such that the >> hash values won't match, then we have no recourse but to bump >> pg_stat_statements version number, and invalidate all existing >> entries. > > What if we simply included the pg_stat_statements version number in > what's shown to the user as the 'hash'? ver#.hash ?
That won't really help matters. There'd still be duplicate entries, from before and after the change, even if we make it immediately obvious which is which. The only reasonable solution in that scenario is to bump PGSS_FILE_HEADER, which will cause all existing entries to be invalidated. This is a hypothetical scenario, and concerns about it are totally orthogonal to the actual question of whether or not the queryid should be exposed... -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
