Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
PostgreSQL Development, 24x7 Support, Training and Services

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group