On Thu, May 24, 2012 at 5:20 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 24 May 2012 16:06, Tom Lane <tgl@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/