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

SELECT is 2-3x slower when used as source for other construct

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 5.5.33a, 10.0.13
    • Fix Version/s: 5.5.40, 10.0.14
    • Environment:
      MariaDB 5.5.33a with TokuDB support
      Gentoo Linux 64bit, kernel 3.11, 2 x E5-2643@3.30GHz, 128 GB RAM, 2 x SSD Intel DC S3700. Server is totally idle, just for this testing purposes.

      Description

      Hi.

      I'm using TokuDB tables with COMPRESSION=tokudb_small. MariaDB 5.5.33a with TokuDB support. Builded from amd64 sources with cmake.

      I have one SELECT, which returns about 100 records with 20 number columns. These records are aggregated from 1 mio records in 3 joined tables, by indexed columns. It's relatively simple, with predictable and clean execution plan.

      This select is running stable about 4,8 seconds. I use SQL_NO_CACHE flag.

      But, when this same SELECT is part of any other simple construct (for example CREATE TABLE [select], or INSERT INTO [select] ON DUPLICATE KEY UPDATE), this query is running 2-3x slower, about 13 seconds.

      In query profile, or status, there are identical informations (Handler_read_key, etc.) for both usages.

      But with one important difference - durations of query steps:

      • in profile of first usage (just SELECT):
      • "Queried about 140000 rows" with duration 0.0518770
      • "Queried about 150000 rows" with duration 0.0504550
      • etc..
      • in profile of second usage (SELECT for CREATE TABLE, or INSERT/UPDATE), profile contains:
      • "Queried about 140000 rows" with duration 0.1185300
      • "Queried about 150000 rows" with duration 0.1221410

      So, when SELECT is part of other construct, this select is about 2-3x slower.

      Just for sure, i used also index-hinting for every joined table. These hints are the same, which EXPLAIN reports. So, execution plan is same in both usages.

      I used also "SQL_NO_CACHE" flag, for securing identical environment. SELECT returns just 100 records, so, there is no big related overhead with creating new temporary table, or inserting/updating rows. When this SELECT is vestured in other SELECT * FROM [select] LIMIT 1, result is the same.

      Do you know about this performance issue?

      Thank you.

      SELECT looks like...
      
      SELECT
        x.col1,
        x.col2,
        (x.col1 - x.col2) AS col3
      FROM (
        SELECT cols [with some SUM, COUNT, AVG aggreations]
        FROM table1
        INNER JOIN table2 ON table2.id = table1.id_x
        INNER JOIN table3 ON table3.id = table2.id_y
        WHERE id_date = 5
        GROUP BY table1.id_z
      ) AS x
      

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              pomyk Patryk Pomykalski added a comment -

              This one states slower updates and deletes, but maybe it's the same issue (disabled bulk fetching):
              https://github.com/Tokutek/ft-engine/issues/75

              Show
              pomyk Patryk Pomykalski added a comment - This one states slower updates and deletes, but maybe it's the same issue (disabled bulk fetching): https://github.com/Tokutek/ft-engine/issues/75
              Hide
              serg Sergei Golubchik added a comment -

              Right, it's https://github.com/Tokutek/ft-engine/issues/143 — bulk fetching is not used where it could've been.
              When it will be fixed in TokuDB, we will get the fix with the next merge.

              Show
              serg Sergei Golubchik added a comment - Right, it's https://github.com/Tokutek/ft-engine/issues/143 — bulk fetching is not used where it could've been. When it will be fixed in TokuDB, we will get the fix with the next merge.
              Hide
              prohaska7 Rich Prohaska added a comment -

              Fixed in tokudb-7.1.8.

              Show
              prohaska7 Rich Prohaska added a comment - Fixed in tokudb-7.1.8.
              Hide
              jan.reges Ján Regeš added a comment -

              Thank you!

              TokuDB 7.1.8 will be released about 08/2014?

              Show
              jan.reges Ján Regeš added a comment - Thank you! TokuDB 7.1.8 will be released about 08/2014?
              Hide
              prohaska7 Rich Prohaska added a comment -

              We have some partial code (on our github tokudb-7.1.8-rc4 branch) that we are testing. We also are investigating a few other situations where bulk fetch may be used. The target for release is middle sept 2014.

              Show
              prohaska7 Rich Prohaska added a comment - We have some partial code (on our github tokudb-7.1.8-rc4 branch) that we are testing. We also are investigating a few other situations where bulk fetch may be used. The target for release is middle sept 2014.
              Hide
              serg Sergei Golubchik added a comment -

              the fix was pulled in with TokuDB 7.5.0

              Show
              serg Sergei Golubchik added a comment - the fix was pulled in with TokuDB 7.5.0
              Hide
              jan.reges Ján Regeš added a comment -

              Thank you, Sergei :-*

              Show
              jan.reges Ján Regeš added a comment - Thank you, Sergei :-*

                People

                • Assignee:
                  serg Sergei Golubchik
                  Reporter:
                  jan.reges Ján Regeš
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: