-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize(Search): Handle LEFT JOIN which concern counting operations lastly #16999
base: main
Are you sure you want to change the base?
Optimize(Search): Handle LEFT JOIN which concern counting operations lastly #16999
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only have few data in my local instance, I cannot really test. Do you have feedback from the customer?
The first customer is delighted and I'm waiting to hear back from a second customer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The performance problem is not related to the fact that there is a COUNT
operation, but is related to the fact that the related table contains millions of rows. IMHO, we should find a more precise way to reorder the JOIN
operations. For instance, we could add a method public function getTableWeight(): int
that would return, for example, an integer from 1 to 10, and use this result to sort the JOIN operations.
For instance, we could assume that CommonDropdown
table does not contains many values, so we could put them at first, and tables related to Softwares
could contains millions of rows and should be joined at last.
In the future, we could even compute the real weight of table once a day/week/whatever and us this real value to compute the JOIN order.
On one customer's instance, we were confronted with major problems of slowness on the software list.
The first 50 softwares took almost 13 seconds to load.
Here is the list of columns displayed on the customer's site
By digging around, I've come to understand that if the column that counts the number of installations (
glpi_items_softwareversions_37010ce8f4633da91ded3e0a4c256dc9
) is followed by any otherLEFT JOIN
glpi_states_0a35c270152be19b5c8a485502badcd7
, the SQL query takes an enormous amount of time (13.877 sec).Conversely, if the column counting the number of installations is the last, the loading time is very reasonable (0.008 sec).
I have therefore deduced that there is a performance problem with the order of the
LEFT JOIN
when GLPI creates the SQL query.An
EXPLAIN
of the SQL query seems to confirm thisSQL query with "bad"
LEFT JOIN
order (lastLEFT JOIN
onglpi_states
useUsing join buffer
instead ofwhere
(seeExtra
column) maybe becausekey
,key_len
andref
arenull
)SQL query with "good" LEFT JOIN order (only
where
is used seeExtra
column)The idea of this PR is therefore to reorganise the searchoption order according to
datatype
If equal to
count
put at the end, otherwise at the beginning