Re: pgbench logging broken by time logic changes
Hannu Krosing <hannuk@google.com>
From: Hannu Krosing <hannuk@google.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: nagata@sraoss.co.jp, coelho@cri.ensmp.fr, gregsmithpgsql@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>,
david.christensen@crunchydata.com
Date: 2021-07-08T14:46:51Z
Lists: pgsql-hackers
On Thu, Jun 17, 2021 at 7:18 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > I'm not sure we have transaction lasts for very short time that > nanoseconds matters. > Nanoseconds may not matter yet, but they could be handy when for example we want to determine the order of parallel query executions. We are less than an order of magnitude away from being able to do 1M inserts/updates/deletes per second, so microseconds already are not always 100% reliable. We could possibly move to using LSNs fetched as part of the queries for this case, but this will surely introduce more problems than it solves :) Cheers ----- Hannu Krosing Google Cloud - We have a long list of planned contributions and we are hiring. Contact me if interested.
Commits
-
Fix pgbench timestamp bugs.
- 5614a0f78eaa 14.0 landed
- 0e39a608ed55 15.0 landed
-
Fix pattern matching logic for logs in TAP tests of pgbench
- 0efd2a1a66dd 11.13 landed
- 79ff96aa9d9a 12.8 landed
- 7a9eaf111ac0 13.4 landed
- c13585fe9e55 14.0 landed
-
pgbench: Improve time logic.
- 547f04e7348b 14.0 cited
-
pgbench: Synchronize client threads.
- aeb57af8e640 14.0 cited
-
pgbench: refactor handling of stats tracking
- b60376649600 9.6.0 cited