PGM-C-client

The PGM-C order-entry workload, driven from the client instead of from PL/pgSQL functions: each transaction is a Lua script that sends every statement in its own round trip, reads the results it needs and decides what to do next, the way an application without stored procedures behaves.

pgmeter spec new pgm-c-client -o .
pgmeter -d benchmark init --spec pgm-c-client -s 10 -j 4
pgmeter -d benchmark run  --spec pgm-c-client -c 8 -T 120 -r 60

The schema, the data, the transaction mix, the input distributions, the transaction profiles and the designed 1% New-Order rollback are the same as PGM-C’s; the two specs share their loader and their Lua helpers. What differs is where the transaction logic runs:

On the same server PGM-C-client reports a much lower rate than PGM-C, and the ratio between the two is a direct measure of what the network and the protocol cost your application. Use PGM-C-client when that is what you want to see, or when the thing under test is a connection pooler, a proxy or a network path. Use PGM-C to measure the server itself.

The error you should expect is the same: about 1% of New-Orders end with New-Order rollback: unknown item, which is the specification’s rollback, counted as an error. The deviations from TPC-C listed on the PGM-C page apply here too.

Because the scripts read a value, compute on it and write it back, they lock what they read: New-Order takes its stock rows FOR UPDATE, in key order like the PL/pgSQL function, so concurrent orders neither lose a decrement nor deadlock, and Delivery picks each district’s oldest order with FOR UPDATE SKIP LOCKED, so two deliveries of the same warehouse take different orders.