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

Re: Hash id in pg_stat_statements

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash id in pg_stat_statements
Date: 2012-10-01 16:18:52
Message-ID: CAEYLb_WQofi+JDMCAgFMiop7MfF_O4ZB+Tmr-HNjP=J9iKv3Yg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 1 October 2012 17:12, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Peter, all,
>
> * Peter Geoghegan (peter(at)2ndquadrant(dot)com) wrote:
>> Well, I'll point out once again that the argument about its stability
>> is invalid, because we serialise the entries to disk. If a point
>> release changes the representation of the query tree such that the
>> hash values won't match, then we have no recourse but to bump
>> pg_stat_statements version number, and invalidate all existing
>> entries.
>
> What if we simply included the pg_stat_statements version number in
> what's shown to the user as the 'hash'?  ver#.hash ?

That won't really help matters. There'd still be duplicate entries,
from before and after the change, even if we make it immediately
obvious which is which. The only reasonable solution in that scenario
is to bump PGSS_FILE_HEADER, which will cause all existing entries to
be invalidated.

This is a hypothetical scenario, and concerns about it are totally
orthogonal to the actual question of whether or not the queryid should
be exposed...

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2012-10-01 16:25:43
Subject: Re: WIP checksums patch
Previous:From: Stephen FrostDate: 2012-10-01 16:12:41
Subject: Re: Hash id in pg_stat_statements

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