Re: [HACKERS] 64-bit queryId?
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] 64-bit queryId? |
Дата | |
Msg-id | 20170930160619.4rdct56l3zmm2azf@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] 64-bit queryId? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: