On 15 November 2012 13:10, Magnus Hagander <magnus@hagander.net> wrote:
>> Well, forgive me for pointing this out, but I did propose that the
>> hash be a 64-bit value (which would have necessitated adopting
>> hash_any() to produce 64-bit values), but you rejected the proposal. I
>> arrived at the same probability for a collision as you did and posted
>> in to the list, in discussion shortly after the normalisation stuff
>> was committed.
>
> What was the argument for rejecting it? Just that it required
> hash_any() to be adapted?
I think so, yes. It just wasn't deemed necessary. Note that hash_any()
has a comment that says something like "if you want to adapt this so
that the Datum returned is a 64-bit integer, the way to do that
is...". I followed this advice in a revision of the pg_stat_statements
normalisation patch, and preserved compatibility by using a macro,
which Tom objected to.
> Now that we have a very clear use case where this would help, perhaps
> it's time to re-visit this proposal?
Perhaps. I think that the issue of whether or not a 64-bit integer is
necessary is totally orthogonal to the question of whether or not we
should expose the hash. The need to aggregate historical statistics
just doesn't appreciably alter things here, I feel. The number of
discrete queries that an application will execute in a week just isn't
that different from the number that it will ever execute, I suspect.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
