Re: Hash id in pg_stat_statements

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash id in pg_stat_statements
Date: 2012-10-01 15:22:21
Message-ID: CAEYLb_UT+YUY3jDKWeVSs+=GtkAE3SL83n9=OwzxnGG8H7QU7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1 October 2012 15:22, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-01 15:33:01 Re: embedded list v3
Previous Message Robert Haas 2012-10-01 15:06:12 Re: BUG #7534: walreceiver takes long time to detect n/w breakdown