Re: [HACKERS] 64-bit queryId?
| От | Peter Geoghegan |
|---|---|
| Тема | Re: [HACKERS] 64-bit queryId? |
| Дата | |
| Msg-id | CAH2-Wzk4VALL5bxYZ54jAFdFGzdrNZk00xMH8WbAJjzJLJ_aRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] 64-bit queryId? (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [HACKERS] 64-bit queryId?
Re: [HACKERS] 64-bit queryId? Re: [HACKERS] 64-bit queryId? Re: [HACKERS] 64-bit queryId? |
| Список | 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 -- 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 по дате отправления: