Skip to content
  • Steinar H. Gunderson's avatar
    443a01ae
    Bug #31310238: SUPPORT SORTING MULTIPLE TABLES [patch 2/5, implementation] [noclose] · 443a01ae
    Steinar H. Gunderson authored
    Make filesort support sorting a join of multiple tables, not just a single
    table. The biggest change is that the sort types that depend on row IDs
    need to support multiple ones instead of just one -- this means that we
    can do such sorts without having to materialize them (StreamingIterator
    already took care of most of the common cases, although with a fair bit
    of unneccessary copying).
    
    Filesort now takes in the estimate for number of rows (only used for
    excluding priority queue, if there are so few rows that we assume multiple
    buffers are not needed) from the estimates in the access path instead of asking
    the table, since there's not necessarily “one table” anymore. For some tests,
    this actually gives a more precise estimate, although it's likely to be fairly
    inconsequential in practice.
    
    Nothing in the executor currently sets up access paths with such multi-table
    sorts, since fields are always resolved to the temporary table (so it's not
    just a matter of changing), but the new optimizer will.
    
    Change-Id: I5304035b1fa36b622e7d58d5464d6b3ec0e50ba8
    443a01ae
    Bug #31310238: SUPPORT SORTING MULTIPLE TABLES [patch 2/5, implementation] [noclose]
    Steinar H. Gunderson authored
    Make filesort support sorting a join of multiple tables, not just a single
    table. The biggest change is that the sort types that depend on row IDs
    need to support multiple ones instead of just one -- this means that we
    can do such sorts without having to materialize them (StreamingIterator
    already took care of most of the common cases, although with a fair bit
    of unneccessary copying).
    
    Filesort now takes in the estimate for number of rows (only used for
    excluding priority queue, if there are so few rows that we assume multiple
    buffers are not needed) from the estimates in the access path instead of asking
    the table, since there's not necessarily “one table” anymore. For some tests,
    this actually gives a more precise estimate, although it's likely to be fairly
    inconsequential in practice.
    
    Nothing in the executor currently sets up access paths with such multi-table
    sorts, since fields are always resolved to the temporary table (so it's not
    just a matter of changing), but the new optimizer will.
    
    Change-Id: I5304035b1fa36b622e7d58d5464d6b3ec0e50ba8
Loading