Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4592

Correlated subquery produces inefficient optimizer plan for INFORMATION_SCHEMA

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.0.2, 5.5.31
    • Fix Version/s: 10.0, 5.5
    • Component/s: None
    • Labels:

      Description

      (initial placeholder... ticket will be enhanced incrementally, I apologize for initial missing informations)

      apparently MariaDB 10.0.1, MariaDB 5.5.30, MySQL 5.5, 5.6 and Percona 5.5 are having the exact same behavior with a query that could be optimized, but I was expecting to run extremely quickly

      It has correlated subqueries to populate some of the outputted columns,
      but none of these are involved in the general WHERE clause

      plus, these is also a LIMIT 18...
      which brings down the whole thing to a very small dataset

      I was expecting the query optimizer to apply first the WHERE clause,
      than the LIMIT... then at last, execute the JOINS and the SUBQUERIES

      Instead (in my case I have a 5mio row table, and the database/versions I mentioned above, are all computing first all the joins and all the subqueries, bringing everything in memory, and then as last thing applying the WHERE and the LIMIT... which is very... ehhrrr... nonsense ...IMHO)

      I found a ticket, opened since 2007, on mysql.org, hitting exactly this scenario

      I will provide a suitable test to be filled into this ticket (as all my tests are now based on internal tools,
      and data dumps that can't be practically attached here), for now, I'm looking for comments...

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            zeph Guido Serra added a comment -

            p.s. for the administrator, could u grant me EDIT permission on the ticket? so that I can enhance it with extra details

            Show
            zeph Guido Serra added a comment - p.s. for the administrator, could u grant me EDIT permission on the ticket? so that I can enhance it with extra details
            Hide
            serg Sergei Golubchik added a comment -

            done. feel free to add more information

            Show
            serg Sergei Golubchik added a comment - done. feel free to add more information
            Hide
            zeph Guido Serra added a comment -

            tnx @Sergei

            Show
            zeph Guido Serra added a comment - tnx @Sergei
            Hide
            zeph Guido Serra added a comment -

            uhmm... hold on...
            seems to be that my issue is specifically related to SQL_CALC_FOUND_ROWS
            forcing a full unnecessary construction of LEFT JOINS to get the count of results
            (without that, on a main table having 3mio rows, and the LEFT JOINS, and WHERE clause and the LIMIT...
            it takes 0.034 secs... against the 14.5 secs having the SQL_CALC_FOUND_ROWS)

            I can't isolate what I thought was the issue... therefore... closing

            I'll try to understand the code around the SQL_CALC_FOUND_ROWS stmt

            Show
            zeph Guido Serra added a comment - uhmm... hold on... seems to be that my issue is specifically related to SQL_CALC_FOUND_ROWS forcing a full unnecessary construction of LEFT JOINS to get the count of results (without that, on a main table having 3mio rows, and the LEFT JOINS, and WHERE clause and the LIMIT... it takes 0.034 secs... against the 14.5 secs having the SQL_CALC_FOUND_ROWS) I can't isolate what I thought was the issue... therefore... closing I'll try to understand the code around the SQL_CALC_FOUND_ROWS stmt
            Hide
            zeph Guido Serra added a comment - - edited

            just FYI... on a Macbook Air (same of the test above done on MariaDB10.0.1)
            with... MySQL 5.5.29

            and the same settings:

            • innodb_file_per_table
            • innodb_write_io_threads=16
            • innodb_read_io_threads=16
            • sort_buffer_size = 256M

            this specific bad query takes 159.7 secs

            Show
            zeph Guido Serra added a comment - - edited just FYI... on a Macbook Air (same of the test above done on MariaDB10.0.1) with... MySQL 5.5.29 and the same settings: innodb_file_per_table innodb_write_io_threads=16 innodb_read_io_threads=16 sort_buffer_size = 256M this specific bad query takes 159.7 secs
            Hide
            zeph Guido Serra added a comment -

            @Sergei: forgive me... feel free to close this ticket as a Won't Fix... it is NOT a MariaDB concern

            Show
            zeph Guido Serra added a comment - @Sergei: forgive me... feel free to close this ticket as a Won't Fix... it is NOT a MariaDB concern
            Hide
            zeph Guido Serra added a comment -

            for reference... http://bugs.mysql.com/bug.php?id=46648

            u probably have a similar situation... ur call if it is something bothering u... or not

            Show
            zeph Guido Serra added a comment - for reference... http://bugs.mysql.com/bug.php?id=46648 u probably have a similar situation... ur call if it is something bothering u... or not

              People

              • Assignee:
                Unassigned
                Reporter:
                zeph Guido Serra
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: