From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statments queryid |
Date: | 2012-05-25 08:04:13 |
Message-ID: | CABUevEwn37O-TSLTuM0e7A_cDzPv5tO01NyxNCzBYCBvKXgCQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 24, 2012 at 5:20 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 24 May 2012 16:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Alex | 2012-05-25 09:11:15 | Re: libpq URL syntax vs SQLAlchemy |
Previous Message | Pavel Stehule | 2012-05-25 07:36:59 | proposal: features for simpler integration psql to bash |