Re: pg_stat_statments queryid

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/

In response to

Browse pgsql-hackers by date

  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