Bug 3958 - TRACE timings are misleading with CREATE TABLE statements
Summary: TRACE timings are misleading with CREATE TABLE statements
Status: NEW
Alias: None
Product: SQL
Classification: Unclassified
Component: all (show other bugs)
Version: -- development
Hardware: x86_64 (amd64/em64t) Linux
: Normal enhancement
Assignee: SQL devs
Depends on:
Reported: 2016-03-21 10:11 CET by Roberto Cornacchia
Modified: 2016-04-11 11:46 CEST (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Roberto Cornacchia 2016-03-21 10:11:48 CET
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Build Identifier: 

When I do 
sql> set optimizer='sequential_pipe';
sql> TRACE CREATE TABLE x AS <select statement> WITH DATA;

I get an output similar to this:

| ticks    | statement                        |
|    13212 | <select statement>               |
|  9057211 | <select statement>               |
|        0 | end user.s41_1;                  |
| 15027376 | function user.s41_1(...):void;   |
| 15027472 | X_4=0@0:void := user.s41_1(...); |
57 tuples (15.0s)

That is misleading, because then numbers just don't add up. 
In the toy example above, 9057211 + 13212 is the cost of the select statement, but the total cost is reported as 15027472. 

What is missing is the cost of the CREATE TABLE statement itself.
Is it possible to include that cost in the trace?

Reproducible: Always
Comment 1 Roberto Cornacchia 2016-03-21 10:25:04 CET
In case including the cost of the create statement isn't possible, I would expect the reported cost of the function (last two lines of the trace), to report the actual cost of the select statement (the sum of all previous statements), while the query timing - 57 tuples (15.0s) - stays the same.