1819.9.67
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.66
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.65
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.64
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.63
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.62
|
|
|
Jimmy Yang |
13 years ago
|
|
|
1819.9.61
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.60
|
|
|
Stewart Smith |
13 years ago
|
|
|
1819.9.59
|
|
|
Vasil Dimov |
13 years ago
|
|
|
1819.9.58
|
|
Merge Revision revid:vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a from MySQL InnoDB
Original revid:vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
Original Authors: Vasil Dimov <vasil.dimov@oracle.com> Original commit message: Fix Bug#53761 RANGE estimation for matched rows may be 200 times different
Improve the range estimation algorithm.
Previously: For a given level the algo knows the number of pages in the requested range and the n
With this change: Same idea, but peek a few (10) of the intermediate pages to get a better estimate of
In the bug report one of the examples has a btree with a snippet of the leaf level li page1(899 records), page2(1 record), page3(1 record), page4(1 record) so when trying to estimate, the previous algo, assumed there are average (899+1)/2=45 Fix Bug#53761 RANGE estimation for matched rows may be 200 times different
Improve the range estimation algorithm.
Previously: For a given level the algo knows the number of pages in the requested range and the number of records on the leftmost and the rightmost page. Then it assumes all pages in between contain the average between the two border pages and multiplies this average number by the number of intermediate pages.
With this change: Same idea, but peek a few (10) of the intermediate pages to get a better estimate of the average number of records per page. If there are less than 10 intermediate pages then all of them will be scanned and the result will be precise, not an estimation.
In the bug report one of the examples has a btree with a snippet of the leaf level like this: page1(899 records), page2(1 record), page3(1 record), page4(1 record) so when trying to estimate, the previous algo, assumed there are average (899+1)/2=450 records per page which went terribly wrong. With this change page2 and page3 will be read and the exact number of records will be returned.
Approved by: Sunny (rb://401)
|
Vasil Dimov |
13 years ago
|
|
|
1819.9.57
|
|
|
Inaam Rana |
13 years ago
|
|
|
1819.9.56
|
|
|
Marko Mäkelä |
13 years ago
|
|
|
1819.9.55
|
|
|
Marko Mäkelä |
13 years ago
|
|
|
1819.9.54
|
|
|
Calvin Sun |
13 years ago
|
|
|
1819.9.53
|
|
|
Inaam Rana |
13 years ago
|
|
|
1819.9.52
|
|
|
Inaam Rana |
13 years ago
|
|
|
1819.9.51
|
|
|
Marko Mäkelä |
13 years ago
|
|
|
1819.9.50
|
|
|
MySQL Build Team |
13 years ago
|
|
|
1819.9.49
|
|
|
MySQL Build Team |
13 years ago
|
|
|
1819.9.48
|
|
|
Sunny Bains |
13 years ago
|
|
|