Re: 64-bit queryId?
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-30T15:39:01Z
Lists: pgsql-hackers
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. I have heard complaints about a number of different things in pg_stat_statements, like the fact that we don't always manage to replace constants with '?'/'$n' characters in all cases. I heard about that quite a few times during my time at Heroku. But never this. -- Peter Geoghegan
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