[MDEV-30771] Optimizer trace: table_scan.rows is traced as integer, change to double Created: 2023-03-02  Updated: 2023-03-28  Resolved: 2023-03-27

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5, 10.6, 10.8, 10.9, 10.10, 10.11, 11.0
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Sergei Petrunia Assignee: Sergei Petrunia
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

I am looking at 10.6 but earlier versions are likely affected, too.

Looking at outputs like this

              {
 
                "table": "ix",
 
                "table_scan": {
 
                  "rows": 1289434,
 
                  "cost": 23103
 
                }

"cost" is always integer?
Debugging the code in add_table_scan_values_to_trace() (one of the TWO places which log "table_scan" objects). I see that the cost is double but is written as integer.

Please make sure it is written as double in BOTH places, starting from the earliest applicable version.

 Comments   
Comment by Rex Johnston [ 2023-03-06 ]

Hi Sergei,

as far as i could tell, these are actually doubles and what you are seeing is the result of the printf format %g truncating the number. Attached is my suggestion for making it clear what sort of number is being printed, controlled by some #defines. Unfortunately it's changed a lot of the optimizer trace outputs in mysql-test, but what is truncated is arguably not useful. I've looked through all of them.

Thanks, Rex

Comment by Sergei Petrunia [ 2023-03-27 ]

Hi Rex,

Thanks for pointing this out. "rows" is actually an integer, I got confused as I was thinking we were printing "cost", which is double.

Also was looking at a customer's trace where cost happened to be an integer...

Comment by Sergei Petrunia [ 2023-03-27 ]

Closing as Not-a-bug

Generated at Thu Feb 08 10:18:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.