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 stores > statistics to disk by default, and can only ever recognise statement > equivalence based on the (dbid, userid, queryid) hash key.
Yes, if that's actually a problem, the whole way how pg_stat_statements stores it's data persistently across restarts needs to be rewritten. In a way that introduces an identifier that *is* stable across restarts. In which case we could just expose that identifier instead, and we're done. What exactly is it that could/would be unstable across a reboot? Not being stable across an initdb is of course a whole different story - I think it's perfectly reasonable not to be that. >> Aside from the OID dependence problem, we might well >> change the way the hash is calculated in minor releases, for example by >> adding or removing struct fields. > > You've already invalidated the saved statistics if you do that, so all > bets are off anyway. If you have to do it, it'll be necessary to bump > PGSS_FILE_HEADER, so that pg_stat_statements will be cleared upon > restart. That will in turn necessitate documenting the issue in the > minor version release notes. I'd hope to avoid that, but it doesn't > seem to me that the situation is made any worse than before by > exposing the value. On the contrary, it could help users to understand > where the problem may have affected them. Agreed. We already break something very user-visible in this case. Two symptoms of the same breakage is really not that big an issue, IMO, compared to the big gains to be had. > If you don't expose the value, users are going to do this sort of > thing anyway, but will be far worse off due to using the query text or > a hash thereof instead of the internal value. Exactly. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
