Re: 64-bit queryId?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-30T15:50:08Z
Lists: pgsql-hackers
On Sat, Sep 30, 2017 at 11:39 AM, Peter Geoghegan <pg@bowt.ie> wrote: > 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. Most people don't change > pg_stat_statements.max, so the probability of a collision is more like > 1%. And, that's the probability of *any* collision, not the > probability of a collision that the user actually cares about. The > majority of entries in pg_stat_statements among those ten thousand > will not be interesting. Often, 90%+ will be one-hit wonders. If that > isn't true, then you're probably not going to find pg_stat_statements > very useful, because you have nothing to focus on. Well, I think that the fact that pg_stat_statements.max exists at all is something that could be fixed now that we have DSA. It's hard to tell right now whether the fact that we don't hear about collisions is an artifact of that limit or of the underlying workload. Also, if someone did have collisions, how would they even know? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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