[MDEV-4592] Correlated subquery produces inefficient optimizer plan for INFORMATION_SCHEMA Created: 2013-05-27  Updated: 2022-11-29  Resolved: 2022-11-29

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.0.2, 5.5.31
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Guido Serra Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: upstream


 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...



 Comments   
Comment by Guido Serra [ 2013-05-27 ]

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

Comment by Sergei Golubchik [ 2013-05-27 ]

done. feel free to add more information

Comment by Guido Serra [ 2013-05-27 ]

tnx @Sergei

Comment by Guido Serra [ 2013-05-28 ]

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

Comment by Guido Serra [ 2013-05-28 ]

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

Comment by Guido Serra [ 2013-05-28 ]

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

Comment by Guido Serra [ 2013-05-28 ]

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

Generated at Thu Feb 08 06:57:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.