On Sat, Dec 29, 2012 at 6:37 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 29 December 2012 12:21, Daniel Farina <drfarina@acm.org> wrote:
>> These were not express goals of the patch, but so long as you are
>> inviting features, attached is a bonus patch that exposes the queryid
>> and also the notion of a "statistics session" that is re-rolled
>> whenever the stats file could not be read or the stats are reset, able
>> to fully explain all obvious causes of retrograde motion in
>> statistics. It too is cumulative, so it includes the under-estimation
>> field.
>
> Cool.
>
> I had a thought about Tom's objection to exposing the hash value. I
> would like to propose a compromise between exposing the hash value and
> not doing so at all.
As I recall, the gist of this objection had to do with a false sense
of stability of the hash value, and the desire to enforce the ability
to alter it. Here's an option: xor the hash value with the
'statistics session id', so it's *known* to be unstable between
sessions. That gets you continuity in the common case and sound
deprecation in the less-common cases (crashes, format upgrades, stat
resetting).
A change in hash function should also then necessitate changing the
stat file header.
Another more minor issue is the hard-wiring of the precision of the
id. For that reason, I have thought it reasonable to expose this as a
string also.
--
fdr
