Re: Patch: add timing of buffer I/O requests - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id CA+TgmoZz6xvbU3Xb9XwQS+8owiS5mtia4cLb9cJpKw88zRCxDQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  ("ktm@rice.edu" <ktm@rice.edu>)
Responses Re: Patch: add timing of buffer I/O requests  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Patch: add timing of buffer I/O requests  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Patch: add timing of buffer I/O requests  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Wed, Apr 11, 2012 at 9:02 AM, ktm@rice.edu <ktm@rice.edu> wrote:
> By using all 64-bits of the hash that we currently calculate, instead
> of the current use of 32-bits only, the collision probabilities are
> very low.

That's probably true, but I'm not sure it's worth worrying about -
one-in-four-billion is a pretty small probability.

On the broader issue, Peter's argument here seems to boil down to
"there is probably a reason why this is useful" and Tom's argument
seems to boil down to "i don't want to expose it without knowing what
that reason is". Peter may well be right, but that doesn't make Tom
wrong.  If we are going to expose this, we ought to be able to
document why we have it, and right now we can't, because we don't
*really* know what it's good for, other than raising awareness of the
theoretical possibility of collisions, which doesn't seem like quite
enough.

On another note, I think this is a sufficiently major change that we
ought to add Peter's name to the "Author" section of the
pg_stat_statements documentation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PREPARE TRANSACTION compatibility?
Next
From: Thom Brown
Date:
Subject: Re: [COMMITTERS] pgsql: Add new replication mode synchronous_commit = 'write'.