noisepage-checks[bot]
commented
3 years ago Minor Decrease in Performance
Be warned: this PR may have decreased the throughput of the system slightly.
| tps (%change) | benchmark_type | wal_device | details |
|---|---|---|---|
| -2.15% | tpcc | RAM disk | Detailsmaster tps=22952.93, commit tps=22459.58, query_mode=extended, benchmark_type=tpcc, scale_factor=32.0000, terminals=32, client_time=60, weights={'Payment': 43, 'Delivery': 4, 'NewOrder': 45, 'StockLevel': 4, 'OrderStatus': 4}, wal_device=RAM disk, max_connection_threads=32 |
| -0.58% | tpcc | None | Detailsmaster tps=29633.59, commit tps=29462.21, query_mode=extended, benchmark_type=tpcc, scale_factor=32.0000, terminals=32, client_time=60, weights={'Payment': 43, 'Delivery': 4, 'NewOrder': 45, 'StockLevel': 4, 'OrderStatus': 4}, wal_device=None, max_connection_threads=32 |
| 0.52% | tpcc | HDD | Detailsmaster tps=21942.79, commit tps=22057.93, query_mode=extended, benchmark_type=tpcc, scale_factor=32.0000, terminals=32, client_time=60, weights={'Payment': 43, 'Delivery': 4, 'NewOrder': 45, 'StockLevel': 4, 'OrderStatus': 4}, wal_device=HDD, max_connection_threads=32 |
| 7.51% | tatp | RAM disk | Detailsmaster tps=6532.22, commit tps=7022.79, query_mode=extended, benchmark_type=tatp, scale_factor=1.0000, terminals=16, client_time=60, weights={'GetAccessData': 35, 'UpdateLocation': 14, 'GetNewDestination': 10, 'GetSubscriberData': 35, 'DeleteCallForwarding': 2, 'InsertCallForwarding': 2, 'UpdateSubscriberData': 2}, wal_device=RAM disk, max_connection_threads=32 |
| 1.0% | tatp | None | Detailsmaster tps=7466.3, commit tps=7540.99, query_mode=extended, benchmark_type=tatp, scale_factor=1.0000, terminals=16, client_time=60, weights={'GetAccessData': 35, 'UpdateLocation': 14, 'GetNewDestination': 10, 'GetSubscriberData': 35, 'DeleteCallForwarding': 2, 'InsertCallForwarding': 2, 'UpdateSubscriberData': 2}, wal_device=None, max_connection_threads=32 |
| 7.9% | tatp | HDD | Detailsmaster tps=6347.99, commit tps=6849.23, query_mode=extended, benchmark_type=tatp, scale_factor=1.0000, terminals=16, client_time=60, weights={'GetAccessData': 35, 'UpdateLocation': 14, 'GetNewDestination': 10, 'GetSubscriberData': 35, 'DeleteCallForwarding': 2, 'InsertCallForwarding': 2, 'UpdateSubscriberData': 2}, wal_device=HDD, max_connection_threads=32 |
codecov[bot]
Description
SQL allows queries to have duplicate table aliases as long as they are at different query depths. For example the following is valid SQL SELECT FROM foo AS f WHERE f.a IN (SELECT a FROM foo AS f) Additionally if a table is not given an alias then we assign it an alias equal to it's name. Meaning that the following query will result in "foo" being a duplicate table alias SELECT FROM foo WHERE a IN (SELECT a FROM foo) The optimizer assumes that all table aliases will be unique, so these types of queries fail.
The solution is to change the type of the table alias in TableRef from string to AliasType, and assign a unique serial number to all TableRefs in a query.
The table name attribute of ColumnValueExpression actually corresponds to the table alias. So one consequence of this change was that we need to also update ColumnValueExpression to have an AliasType attribute for it's table alias. We also need to make sure that the serial number in the ColumnValueExpression's AliasType matches the serial number in the TableRef's AliasType so they could be matched up during optimization and query execution. This is handled in the binder.
This PR does not add supports for duplicate table aliases in CTEs.
Works towards fixing #1229
Remaining tasks
N/A
Performance
N/A
Further work
Address duplicate table aliases in CTEs