[Maria-developers] 5.5 merge: sql_select.cc
Hi. Here I'll list changesets that cause conflicts and ask what to do. 1. http://tinyurl.com/63tey39 vs. http://tinyurl.com/5v2pluf it's a fix for bug#49322. both changes are similar, return is moved down. But Igor put it after the while() loop, while Ole John - in the loop, as soon a non-match is found. What difference does it make, I mean the earlier return, what consequences? 2. http://tinyurl.com/69lwrp9 - a big chunk is moved around in test_if_skip_sort_order() that's all, the rest of the file I've merged already. Regards, Sergei
On 06/22/2011 06:05 AM, Sergei Golubchik wrote:
Hi.
Here I'll list changesets that cause conflicts and ask what to do.
1. http://tinyurl.com/63tey39 vs. http://tinyurl.com/5v2pluf
it's a fix for bug#49322. both changes are similar, return is moved down. But Igor put it after the while() loop, while Ole John - in the loop, as soon a non-match is found. What difference does it make, I mean the earlier return, what consequences?
Sorry for the delay with the reply: it took me a significant amount of time to figure out whether Ole's patch covered all cases. It does. His patch saves on condition checks within unnecessary loops, mine on possible shortcuts. It would be optimal to join them together like this: << while (join_tab->first_unmatched && found) { /* The while condition is always false if join_tab is not the last inner join table of an outer join operation. */ JOIN_TAB *first_unmatched= join_tab->first_unmatched; /* Mark that a match for current outer table is found. This activates push down conditional predicates attached to the all inner tables of the outer join. */ first_unmatched->found= 1; for (JOIN_TAB *tab= first_unmatched; tab <= join_tab; tab++) { /* Check all predicates that has just been activated. */ /* Actually all predicates non-guarded by first_unmatched->found will be re-evaluated again. It could be fixed, but, probably, it's not worth doing now. */ if (tab->select_cond && !tab->select_cond->val_int()) { /* The condition attached to table tab is false */ if (tab == join_tab) { found= 0; if (tab->table->reginfo.not_exists_optimize) return NESTED_LOOP_NO_MORE_ROWS; else { /* Set a return point if rejected predicate is attached not to the last table of the current nest level. */ join->return_tab= tab; return (tab->table->reginfo.not_exists_optimize) ? NESTED_LOOP_NO_MORE_ROWS : NESTED_LOOP_OK; } } } /* Check whether join_tab is not the last inner table for another embedding outer join. */ if ((first_unmatched= first_unmatched->first_upper) && first_unmatched->last_inner != join_tab) first_unmatched= 0; join_tab->first_unmatched= first_unmatched; }
Yet I think it should be done with a separate commit. That's why I would advise for 1: Take my complete patch (as it was pushed into maria-5.1 and later merged into 5.3) and add Ole's test cases.
2. http://tinyurl.com/69lwrp9 - a big chunk is moved around in test_if_skip_sort_order()
that's all, the rest of the file I've merged already.
Regards, Sergei
As to 2, ask Monty because he changed a lot of code in this procedure when merging with the latest 5.1. Regards, Igor.
Hi!
"Sergei" == Sergei Golubchik <serg@askmonty.org> writes:
Sergei> Hi. Sergei> Here I'll list changesets that cause conflicts and ask what to do. Sergei> 1. http://tinyurl.com/63tey39 vs. http://tinyurl.com/5v2pluf Sergei> it's a fix for bug#49322. both changes are similar, return is moved Sergei> down. But Igor put it after the while() loop, while Ole John - in the Sergei> loop, as soon a non-match is found. What difference does it make, I mean Sergei> the earlier return, what consequences? Sergei> 2. http://tinyurl.com/69lwrp9 - a big chunk is moved around in Sergei> test_if_skip_sort_order() Yes, it was done as part of merging 5.1 with 5.3. The original test_if_skip_sort_order() had also several limitations, in that it was depending on the order of the keys which key it would use. I made all keys equal. I assume you should be able to take my version as it is (this should be ok if 5.5 changes comes from the changes they did in 5.1) Regards, Monty
participants (3)
-
Igor Babaev
-
Michael Widenius
-
Sergei Golubchik