Re: [HACKERS] 64-bit queryId? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] 64-bit queryId?
Date
Msg-id 20170930160619.4rdct56l3zmm2azf@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] 64-bit queryId?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2017-09-30 12:03:57 -0400, Tom Lane wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > On Sat, Sep 30, 2017 at 7:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> Assuming, however, that you don't manage to prove all known
> >> mathematics inconsistent, what one might reasonably hope to do is
> >> render collisions remote enough that one need not worry about them too
> >> much in practice.
> 
> > Isn't that already true in the case of queryId? I've never heard any
> > complaints about collisions.
> 
> More to the point: with 32-bit IDs, it's apparent that you shouldn't
> really rely on them being unique, and should design your usage so that
> it will survive collisions.  Robert seems to be arguing that if we
> merely made the IDs wider, it would be okay to design applications that
> don't allow for that and would fail hard on a collision.  I'm reminded
> of Weinberg's famous line "If builders built houses the way programmers
> build programs, the first woodpecker to come along would destroy
> civilization".

I think you're putting words and intent into Robert's mouth.  If you
design a hashtable you're concerned about unnecessary collisions, even
if you're aware of them.  Additionally, it's not clear you always can do
all that much about the collisions, without accepting undue overhead -
see e.g. pg_stat_statements.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] 64-bit queryId?
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] 64-bit queryId?