Re: Hash id in pg_stat_statements
От | Magnus Hagander |
---|---|
Тема | Re: Hash id in pg_stat_statements |
Дата | |
Msg-id | CABUevEzQ8non_nCnJ27p48wiMR86fNDQiyNNdA-WswL21EMkeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hash id in pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hash id in pg_stat_statements
Re: Hash id in pg_stat_statements |
Список | pgsql-hackers |
On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: