pt-query-digest doesn't understand Tmp_table_sizes > 2^32
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
if any request has an value slowlog attribute Tmp_table_sizes > 2 ^ 32 (ie 2 ^ 32 +1), then pt-query-digest in the report shows:
Attribute pct total min max avg 95% stddev median
Tmp tbl size 0 0 0 0 0 0 0 0
command line:
pt-query-digest --explain h=localhost,
Versions:
percona-toolkit 2.1.1
mysql 5.1.59-
OS Debian 5.0.10 amd64
Test slowlog:
# User@Host: test[test] @ localhost [127.0.0.1]
# Thread_id: 43782952 Schema: db Last_errno: 0 Killed: 0
# Query_time: 116.945246 Lock_time: 0.000101 Rows_sent: 50 Rows_examined: 28892915 Rows
# Bytes_sent: 21341 Tmp_tables: 1 Tmp_disk_tables: 1 Tmp_table_sizes: 4294967297
# InnoDB_trx_id: 1F22C67C9
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: Yes
# Filesort: Yes Filesort_on_disk: Yes Merge_passes: 26
# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000
# InnoDB_
# InnoDB_
SET timestamp=
select * FROM test.
output:
# Query 1: 0 QPS, 0x concurrency, ID 0x321B2DD737365711 at byte 0 ________
# This item is included in the report because it matches --limit.
# Scores: Apdex = 0.00 [1.0]*, V/M = 0.00
# EXPLAIN sparkline: a
# Query_time sparkline: | ^|
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 100 1
# Exec time 100 117s 117s 117s 117s 117s 0 117s
# Lock time 100 101us 101us 101us 101us 101us 0 101us
# Rows sent 100 50 50 50 50 50 0 50
# Rows examine 100 27.55M 27.55M 27.55M 27.55M 27.55M 0 27.55M
# Rows affecte 0 0 0 0 0 0 0 0
# Rows read 0 0 0 0 0 0 0 0
# Bytes sent 100 20.84k 20.84k 20.84k 20.84k 20.84k 0 20.84k
# Merge passes 100 26 26 26 26 26 0 26
# Tmp tables 100 1 1 1 1 1 0 1
# Tmp disk tbl 100 1 1 1 1 1 0 1
# Tmp tbl size 0 0 0 0 0 0 0 0
# Query size 100 23 23 23 23 23 0 23
# InnoDB:
# IO r bytes 0 0 0 0 0 0 0 0
# IO r ops 0 0 0 0 0 0 0 0
# IO r wait 0 0 0 0 0 0 0 0
# pages distin 100 63.08k 63.08k 63.08k 63.08k 63.08k 0 63.08k
# queue wait 0 0 0 0 0 0 0 0
# rec lock wai 0 0 0 0 0 0 0 0
# Boolean:
# Filesort 100% yes, 0% no
# Filesort on 100% yes, 0% no
# Full scan 100% yes, 0% no
# Tmp table 100% yes, 0% no
# Tmp table on 100% yes, 0% no
# String:
# Databases db
# Hosts localhost
# InnoDB trxID 1F22C67C9
# Last errno 0
# Users test
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s
# 10s+ #######
# Fingerprint
# select * from test
# EXPLAIN /*!50100 PARTITIONS*/
select * FROM test \G
# *******
# id: 1
# select_type: SIMPLE
# table: test
# partitions: NULL
# type: ALL
# possible_keys: NULL
# key: NULL
# key_len: NULL
# ref: NULL
# rows: 8531893
# Extra:
Changed in percona-toolkit: | |
status: | New → Confirmed |
Changed in percona-toolkit: | |
assignee: | nobody → Brian Fraser (fraserbn) |
tags: | added: pt-query-digest wrong-output |
Changed in percona-toolkit: | |
assignee: | Brian Fraser (fraserbn) → nobody |
Alex, is
# Bytes_sent: 21341 Tmp_tables: 1 Tmp_disk_tables: 1 Tmp_table_sizes: 4294967297
real or something you wrote to demonstrate the problem? In other words, do you really have tmp tables > 4G?