Re: Hash id in pg_stat_statements
От | Peter Geoghegan |
---|---|
Тема | Re: Hash id in pg_stat_statements |
Дата | |
Msg-id | CAEYLb_UT+YUY3jDKWeVSs+=GtkAE3SL83n9=OwzxnGG8H7QU7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hash id in pg_stat_statements (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On 1 October 2012 15:22, Magnus Hagander <magnus@hagander.net> wrote: > On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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 think the need to not break stored rules pins down the actual representation of the Query struct in release branches. I'm not prepared to say that it does so absolutely, since of course certain logic could be altered in a way that resulted in different values within the struct or its children, but I'm curious as to when this actually occurred in the past. Discussion about exposing this value aside, it'd obviously be a bit disappointing if we had to invalidate existing statistics in a point release. Still, that situation isn't made any worse by exposing the value, and in fact doing so could aid in helping users to understand the issues involved. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: