Re: 64-bit queryId?
Gavin Flower <gavinflower@archidevsys.co.nz>
From: Gavin Flower <GavinFlower@archidevsys.co.nz>
To: "Joshua D. Drake" <jd@commandprompt.com>,
Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Alexander Korotkov <a.korotkov@postgrespro.ru>,
Peter Geoghegan
<pg@bowt.ie>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-10-02T20:42:42Z
Lists: pgsql-hackers
On 03/10/17 04:02, Joshua D. Drake wrote: > On 10/01/2017 04:22 PM, Robert Haas wrote: >> On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark <stark@mit.edu> wrote: >>> Well these kinds of monitoring systems tend to be used by operations >>> people who are a lot more practical and a lot less worried about >>> theoretical concerns like that. >> >> +1, well said. >> >>> In context the point was merely that the default >>> pg_stat_statements.max of 5000 isn't sufficient to argue that 32-bit >>> values are enough. It wouldn't be hard for there to be 64k different >>> queries over time and across all the databases in a fleet and at that >>> point it becomes likely there'll be a 32-bit collision. >> >> Yeah. >> >> I think Alexander Korotkov's points are quite good, too. >> > > +1 to both of these as well. > > jD > Did a calculation: # probability of collision 54561 0.499993 54562 0.500005 Essentially, you hit a greater than 50% chance of a collision before you get to 55 thousand statements. Cheers, Gavin
Commits
-
pg_stat_statements: Add a comment about the dangers of padding bytes.
- 2959213bf33c 11.0 landed
-
pg_stat_statements: Widen query IDs from 32 bits to 64 bits.
- cff440d36869 11.0 landed