From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hash id in pg_stat_statements |
Date: | 2012-10-01 14:22:14 |
Message-ID: | CABUevEzQ8non_nCnJ27p48wiMR86fNDQiyNNdA-WswL21EMkeg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Can we please expose the internal hash id of the statements in
>> pg_stat_statements?
>
>> I know there was discussions about it earlier, and it wasn't done with
>> an argument of it not being stable between releases (IIRC).
>
> Worse than that: it could change across a minor version update. These
> are internal data structures we're hashing, and we've been known to
> have to change them for bug-fix purposes.
As Peter pointed out, when we do that we have to change the file
format anyway, and wipe the statistics. So chaning that is something
we'd have to *note*.
>> I've now run into multiple customer installations where it would be
>> very useful to have. The usecase is mainly storing snapshots of the
>> pg_stat_statements output over time and analyzing those.
>
> Doesn't that immediately refute your claim that unstable hash values
> would be okay?
No. It means they need to know when it changes, if it changes in a
minor release. Which would obviously have to go in the release notes,
since it would also invalidate any stored statistics in the *general*
view.
As long as we *tell* them under what conditions it might change, I
think it's perfectly fine. Particularly those who are likely to use
this functionality should certainly be capable of understanding that.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-10-01 14:30:01 | Re: pg_malloc() versus malloc(0) |
Previous Message | Bruce Momjian | 2012-10-01 14:12:06 | Re: Oid registry |