Re: Hash id in pg_stat_statements - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Hash id in pg_stat_statements
Date
Msg-id CAEYLb_UT+YUY3jDKWeVSs+=GtkAE3SL83n9=OwzxnGG8H7QU7w@mail.gmail.com
Whole thread Raw
In response to Re: Hash id in pg_stat_statements  (Magnus Hagander <magnus@hagander.net>)
List 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 by date:

Previous
From: Euler Taveira
Date:
Subject: Re: Hash id in pg_stat_statements
Next
From: Tom Lane
Date:
Subject: Re: embedded list v3