HammerDB and TPROC-B

[JonathanBMiller]

Is your feature request related to a problem? Please describe.

I would like to have an automated TPC‑B workload available again. I started with TPC‑B years ago at PervasiveSQL and continued using it in MySQL. The old MySQL test harness included a TPC‑B implementation:

https://g.sugon.com/MariaDB/server/-/blob/5fbfdae130950d0a5a07d4b909f3bf1ff0498d34/mysql-test/include/tpcb.inc

It was extremely useful and even surfaced issues such as this one:

https://bugs.mysql.com/bug.php?id=21842

Although TPC‑B is officially retired, it remains a valuable and sensitive benchmark for exposing engine‑level problems.

Describe the solution you'd like

A simple, automated TPC‑B implementation inside HammerDB. It does not need to be a full modernized benchmark — just a faithful, runnable version similar to what existed in MySQL. It was highly effective at revealing regressions and edge‑case behavior, and I believe it still has value today.

Describe alternatives you've considered

None.

[sm-shaw]

Many thanks for the submission. It certainly does have merit and is technically feasible if/when bandwidth permits. However will not be immediate with other priority tasks. I will raise as a discussion topic at the TPC-OSS. Thanks again.

[crprashant]

Hi @sm-shaw — now that PR #863 is approved, I'd like to pick this up as my next contribution if the timing works on your side.

Proposed approach: land TPROC-B incrementally, starting with PostgreSQL only as a standalone PR (schema, loader, driver, GUI tree entry, CLI/WS bindings, sample scripts, and a short manual section), then iterate to the other engines — MySQL / MariaDB next, followed by Oracle, SQL Server, and Db2 — in follow-up PRs once the PostgreSQL shape is settled. PostgreSQL feels like the most natural first target given TPC-B's historical role there and it keeps the initial review surface small.

Structurally I'd mirror the existing TPROC-H layout (src/postgresql/pgolap.tcl, configpgtpch, loadtpch, <tpch> block in config/postgresql.xml, etc.) and add a parallel TPROC-B path (schema: branches / tellers / accounts / history, driver: the classic four-statement transaction with History insert) rather than modifying TPROC-C/H.

A couple of questions before I start coding so I don't go off-track:

1. Is the overall direction welcome now, or would you prefer to wait for the TPC-OSS discussion outcome you mentioned?
2. Scope of "faithful": happy with a straight port of the original tpcb.inc transaction semantics (1 account/branch/teller update + 1 history insert per tx, no pacing/think time by default), or do you want think-time/keying aligned with TPROC-C style by default?
3. Scaling unit: follow the historical TPC-B "branches × 100k accounts × 10 tellers" layout, with a pg_count_branches equivalent of pg_count_ware?
4. Driver modes: just timed (rampup / duration) for the first cut, same as TPROC-H, and leave test mode for a follow-up? Stored-procs variant later?
5. Naming: tpcb as the internal key and TPROC-B as the user-facing label, matching the TPROC-C/H convention — does that work, or do you prefer a different label to avoid confusion with the retired TPC-B spec?

Happy to post a short design note / outline first if that would help the review. Otherwise I'll start on the PostgreSQL branch once you give the nod.

[sm-shaw]

@crpashant many thanks for the ideas.

Rather than looking at TPC-B, the current focus is on a more strategic direction around transactional workloads, automation and metrics.

I’ll be opening some new issues shortly in these areas — it would be great if you could contribute there as part of this direction.