Third presentation in a speaker series sponsored by the Portland State University Computer Science Department. The series covers PostgreSQL performance with an OLTP (on-line transaction processing) workload called Database Test 2 (DBT-2). This presentation go into detail about what the workload does.

1. PostgreSQL Portland
Performance Practice Project
Database Test 2 (DBT-2)
Details
Mark Wong
markwkm@postgresql.org
Portland State University
February 12, 2009

2. Review
From last time:
Series overview.
◮
DBT-2 background.
◮
__ __
/ ~~~/ . o O ( Questions? )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;

3. Contents
Diving into the DBT-2 test kit.
Workload description
◮
Architecture
◮
Database Schema and Sizing
◮
Transactions
◮
Description
◮
SQL
◮
Note: Default kit behavior will be covered, but almost all
parameters are changeable.

4. Workload Description
Simulate wholesale supplier processing orders. (Manage, sell,
◮
distribute products or services.)
A basic set of operations representing a complex OLTP
◮
application environment.
For example, someone at a terminal (in no particular order):
checks the stock levels in the warehouse.
◮
enters a new order for items the supplier sells.
◮
searches for the status of an order.
◮
enters payment for an order.
◮
processes an order for delivery.
◮

5. DBT-2 Components

6. Database Schema Diagram

7. Database Schema Notes
9 Tables
◮
No foreign key constraints
◮
__ __ /
/ ~~~/ . o O | Is this a good schema |
,----( oo ) | design? |
/ __ __/ /
/| ( |(
^ /___ / |
|__| |__|-quot;

8. Scale Factor
Determines database size.
◮
Determines number of users driving the workload.
◮

9. Scale Factor’s effect on database row counts
Let W be the scale factor, which determines the starting size of the
database1 :
warehouse has W warehouses
◮
district has 10 districts per warehouse
◮
customer has 3,000 customers per district
◮
history has about a row per customer
◮
orders has about a row per customer
◮
order line has 5-15 items per order
◮
About 30% of the orders are new in new order
◮
item is fixed with 100,000 items in the company
◮
stock stocks 100,000 items per warehouse
◮
1
TPC-C Benchmark Specification v5.9 Clause 1.2.1

10. Scale Factor’s effect on database table size
Numbers are in 1,000 bytes per Warehouse in the database 2 :
warehouse - 0.089
◮
district - 0.950
◮
customer - 19,650
◮
history - 1,380
◮
orders - 720
◮
order line - 16,200
◮
new order - 72
◮
item - 8,200
◮
stock - 30.600
◮
2
TPC-C Benchmark Specification v5.9 Clause 4.2.2

11. Scale Factor’s effect on table row size
Numbers are in bytes per Warehouse in the database 3 :
warehouse - 89
◮
district - 95
◮
customer - 655
◮
history - 146
◮
orders - 24
◮
order line - 54
◮
new order - 8
◮
item - 82
◮
stock - 306
◮
3
TPC-C Benchmark Specification v5.9 Clause 4.2.2

12. DBT-2 Transactions
Now descriptions of the 5 transactions and the SQL statements
executed in each transaction.
Delivery - Read/Write
◮
New Order - Read/Write
◮
Order Status - Read Only
◮
Payment - Read/Write
◮
Stock Level - Read Only
◮
Note: Color coded in an attempted to match upcoming charts.
Read
◮
Write
◮
Read/Write
◮

13. Delivery Transaction Description
The Delivery business transaction consists of
processing a batch of 10 new (not yet delivered) orders.
Each order is processed (delivered) in full within the
scope of a read-write database transaction. The number
of orders delivered as a group (or batched) within the
same database transaction is implementation specific.
The business transaction, comprised of one or more (up
to 10) database transactions, has a low frequency of
execution and must complete within a relaxed response
time requirement.
The Delivery transaction is intended to be executed in
deferred mode through a queuing mechanism, rather
than interactively, with terminal response indicating
transaction completion. The result of the deferred
execution is recorded into a result file.4
4
TPC-C Benchmark Specification v5.9 Clause 2.7

14. Delivery Table Touches

15. Delivery SQL Statements
For every district in the table:
SELECT no_o_id UPDATE order_line
FROM new_order SET ol_delivery_d = current_timestamp
WHERE no_w_id = %d WHERE ol_o_id = %s
AND no_d_id = %d AND ol_w_id = %d
AND ol_d_id = %d
DELETE FROM new_order
WHERE no_o_id = %s SELECT SUM(ol_amount * ol_quantity)
AND no_w_id = %d FROM order_line
AND no_d_id = %d WHERE ol_o_id = %s
AND ol_w_id = %d
SELECT o_c_id AND ol_d_id = %d
FROM orders
WHERE o_id = %s UPDATE customer
AND o_w_id = %d SET c_delivery_cnt = c_delivery_cnt + 1,
AND o_d_id = %d c_balance = c_balance + %s
WHERE c_id = %s
UPDATE orders AND c_w_id = %d
SET o_carrier_id = %d AND c_d_id = %d
WHERE o_id = %s
AND o_w_id = %d
AND o_d_id = %d

16. New Order Transaction Description
The New-Order business transaction consists of entering
a complete order through a single database transaction.
It represents a mid-weight, read-write transaction with a
high frequency of execution and stringent response time
requirements to satisfy on-line users. This transaction is
the backbone of the workload. It is designed to place a
variable load on the system to reflect on-line database
activity as typically found in production environments.5
5
TPC-C Benchmark Specification v5.9 Clause 2.4

17. New Order Table Touches

18. New Order SQL Statements
For 10 to 15 items (1% of
transaction fail here causing a
SELECT w_tax
ROLLBACK):
FROM warehouse
WHERE w_id = %d
SELECT i_price, i_name, i_data
SELECT d_tax, d_next_o_id FROM item
FROM district WHERE i_id = %d
WHERE d_w_id = %d
AND d_id = %d SELECT s_quantity, %s, s_data
FOR UPDATE FROM stock
WHERE s_i_id = %d
UPDATE district AND s_w_id = %d
SET d_next_o_id = d_next_o_id + 1
WHERE d_w_id = %d UPDATE stock
AND d_id = %d SET s_quantity = s_quantity - %d
WHERE s_i_id = %d
SELECT c_discount, c_last, c_credit AND s_w_id = %d
FROM customer
WHERE c_w_id = %d INSERT INTO order_line (l_o_id, ol_d_id, ol_w_id,
AND c_d_id = %d ol_number, ol_i_id,
AND c_id = %d ol_supply_w_id,
ol_delivery_d,
INSERT INTO new_order (no_o_id, no_w_id, no_d_id) ol_quantity,
VALUES (%s, %d, %d) ol_amount, ol_dist_info)
VALUES (%s, %d, %d, %d, %d, %d, NULL, %d, %f,
INSERT INTO orders (o_id, o_d_id, o_w_id, o_c_id, ’%s’)
o_entry_d, o_carrier_id,
o_ol_cnt, o_all_local)
VALUES (%s, %d, %d, %d, current_timestamp, NULL,
%d, %d)

19. Order Status Transaction Description
The Order-Status business transaction queries the status
of a customer’s last order. It represents a mid-weight
read-only database transaction with a low frequency of
execution and response time requirement to satisfy
on-line users. In addition, this table includes non-primary
key access to the CUSTOMER table.6
6
TPC-C Benchmark Specification v5.9 Clause 2.6

20. Order Status Table Touches

21. Order Status SQL Statements
Get the customer ID (c id) only if it is not already known.
SELECT c_id SELECT ol_i_id, ol_supply_w_id, ol_quantity,
FROM customer ol_amount, ol_delivery_d
WHERE c_w_id = %d FROM order_line
AND c_d_id = %d WHERE ol_w_id = %d
AND c_last = ’%s’ AND ol_d_id = %d
ORDER BY c_first ASC AND ol_o_id = %s
SELECT c_first, c_middle, c_last, c_balance
FROM customer
WHERE c_w_id = %d
AND c_d_id = %d
AND c_id = %d
SELECT o_id, o_carrier_id, o_entry_d, o_ol_cnt
FROM orders
WHERE o_w_id = %d
AND o_d_id = %d
AND o_c_id = %d
ORDER BY o_id DESC

22. Payment Transaction Description
The Payment business transaction updates the
customer’s balance and reflects the payment on the
district and warehouse sales statistics. It represents a
light-weight, read-write transaction with a high frequency
of execution and stringent response time requirements to
satisfy on-line users. In addition, this transaction includes
non-primary key access to the CUSTOMER table.7
7
TPC-C Benchmark Specification v5.9 Clause 2.5

23. Payment Table Touches

24. Payment SQL Statements (part 1/2)
Get the customer ID (c id) if not
already known.
SELECT w_name, w_street_1, w_street_2, w_city,
w_state, w_zip
SELECT c_id
FROM warehouse
FROM customer
WHERE w_id = %d
WHERE c_w_id = %d
AND c_d_id = %d
UPDATE warehouse
AND c_last = ’%s’
SET w_ytd = w_ytd + %f
ORDER BY c_first ASC
WHERE w_id = %d
SELECT c_first, c_middle, c_last, c_street_1,
SELECT d_name, d_street_1, d_street_2, d_city,
c_street_2, c_city, c_state, c_zip,
d_state, d_zip
c_phone, c_since, c_credit, c_credit_lim,
FROM district
c_discount, c_balance, c_data,
WHERE d_id = %d
c_ytd_payment
AND d_w_id = %d
FROM customer
WHERE c_w_id = %d
UPDATE district
AND c_d_id = %d
SET d_ytd = d_ytd + %f
AND c_id = %d
WHERE d_id = %d
AND d_w_id = %d

25. Payment SQL Statements (part 2/2)
If the customer has good credit:
UPDATE customer
SET c_balance = c_balance - %f,
c_ytd_payment = c_ytd_payment + 1
WHERE c_id = %d
AND c_w_id = %d
AND c_d_id = %d
Otherwise if the customer has bad credit:
UPDATE customer
SET c_balance = c_balance - %f,
c_ytd_payment = c_ytd_payment + 1,
c_data = E’%s’
WHERE c_id = %d
AND c_w_id = %d
AND c_d_id = %d
INSERT INTO history (h_c_id, h_c_d_id, h_c_w_id,
h_d_id, h_w_id, h_date,
h_amount, h_data)
VALUES (%d, %d, %d, %d, %d, current_timestamp,
%f, E’%s %s’)

26. Stock Level Transaction Description
The Stock-Level business transaction determines the
number of recently sold items that have a stock level
below a specified threshold. It represents a heavy
read-only database transaction with a low frequency of
execution, a relaxed response time requirement, and
relaxed consistency requirements.8
8
TPC-C Benchmark Specification v5.9 Clause 2.8

27. Stock Level Table Touches

28. Stock Level SQL Statements
SELECT d_next_o_id
FROM district
WHERE d_w_id = %d
AND d_id = %d
SELECT count(*)
FROM order_line, stock, district
WHERE d_id = %d
AND d_w_id = %d
AND d_id = ol_d_id
AND d_w_id = ol_w_id
AND ol_i_id = s_i_id
AND ol_w_id = s_w_id
AND s_quantity < %d
AND ol_o_id BETWEEN (%d) AND (%d)

29. Stressing the database and the Transaction Mix
The system is stressed by a C program that creates a thread per
district, per warehouse. In other words, a database built with a
scale factor of 10 will have 10 warehouses. Therefore 100 users will
be simulated to represent a distinct person working for each of the
10 districts for each of the 10 warehouses. Each user executes
transaction to the specified approximate mix:
Delivery - 4%
◮
New Order - 55%
◮
Order Status - 4%
◮
Payment - 43%
◮
Stock Level - 4%
◮

30. Thinking and Keying Time
Thinking Time (How long it take Keying Time (How long it takes
to decide what to enter next, to enter data, fixed.)
negative exponential function.) Delivery - 5 seconds
◮
Delivery - 5 seconds
◮
New Order - 18 seconds
◮
New Order - 12 seconds
◮
Order Status - 2 seconds
◮
Order Status - 10 seconds
◮
Payment - 3 seconds
◮
Payment - 12 seconds
◮
Stock Level - 2 seconds
◮
Stock Level - 5 seconds
◮
__ __ /
/ ~~~/ . o O | Can I get a jumbo sized |
,----( oo ) | terminal? |
/ __ __/ /
/| ( |(
^ /___ / |
|__| |__|-quot;

31. __ __
/ ~~~/ . o O ( Comments? Questions? )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;

32. Materials Are Freely Available
PDF
http://www.slideshare.net/markwkm
◮
LTEX Beamer (source)
A
◮ http://git.postgresql.org/?p=~ markwkm/performance-tuning.git

33. Time and Location
When: 2nd Thursday of the month
Location: Portland State University
Room: FAB 86-01 (Fourth Avenue Building)
Map: http://www.pdx.edu/map.html

34. Coming up next time. . .
How to run DBT-2 run the kit.
__ __
/ ~~~/ . o O ( Thank you! )
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;

35. Acknowledgements
Haley Jane Wakenshaw
__ __
/ ~~~/
,----( oo )
/ __ __/
/| ( |(
^ /___ / |
|__| |__|-quot;

36. License
This work is licensed under a Creative Commons Attribution 3.0
Unported License. To view a copy of this license, (a) visit
http://creativecommons.org/licenses/by/3.0/us/; or, (b)
send a letter to Creative Commons, 171 2nd Street, Suite 300, San
Francisco, California, 94105, USA.