-
Bin Su authored
The regression was found in SELECT - OR scenario, which was about 7%-8% according to QA. After testing and verification, two changes would help improve the performance, and current regression is only about 1.7% in the SELECT - OR scenario, which should be acceptable, because overhead for checking instant columns are inevitable. The two changes are mainly about: 1. Two different rec_get_nth_field for record with (rec_get_nth_field_instant) or without(rec_get_nth_field as is) instant columns. Thus for the record without instant columns, there won't be extra checking. 2. Introduce a bit flag in dict_index_t to say if this is clustered index with some instant columns, rather than consulting with the table. From the testing, 1 saved the regression a lot, but without 2, it's not good enough. So it would be nice to pick both. Furthermore, with these two changes, there are also some small improvement in other testing scenarios. RB: 19392 Reviewed-by:
Jimmy Yang <jimmy.yang@oracle.com>
Bin Su authoredThe regression was found in SELECT - OR scenario, which was about 7%-8% according to QA. After testing and verification, two changes would help improve the performance, and current regression is only about 1.7% in the SELECT - OR scenario, which should be acceptable, because overhead for checking instant columns are inevitable. The two changes are mainly about: 1. Two different rec_get_nth_field for record with (rec_get_nth_field_instant) or without(rec_get_nth_field as is) instant columns. Thus for the record without instant columns, there won't be extra checking. 2. Introduce a bit flag in dict_index_t to say if this is clustered index with some instant columns, rather than consulting with the table. From the testing, 1 saved the regression a lot, but without 2, it's not good enough. So it would be nice to pick both. Furthermore, with these two changes, there are also some small improvement in other testing scenarios. RB: 19392 Reviewed-by:
Jimmy Yang <jimmy.yang@oracle.com>
Loading