-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
Could withCount performance be improved? #25522
Comments
The big advantage of the current subquery solution is the simple integration. Adding a JOIN clause is more complicated because you have to adjust the selected columns. By default, Laravel queries select all columns: User::all(); // select * from "users" Joining another table will override columns of the main table (laravel/ideas#347). |
Instead of looking at sql queries, have you tried looking at the query plan? Just do What you described matches a simple case of "the first queries loaded the data from slow disks into fast memory, the second queries loaded the data from faster memory". Also keep in mind that you changed a simple query ( |
Hi there, Welcome to Laravel and we are glad to have you as part of the community. Unfortunately this GitHub area is not for ideas, suggestions etc. This is only for issues/bugs with the framework code itself. I will be closing your ticket here. You are able to open a ticket at https://github.com/laravel/ideas Alternatively you are able to open a PR using the Contributions guidelines: https://laravel.com/docs/5.7/contributions#which-branch If you feel I've closed this issue in error, please provide more information about how this is a framework issue, and I'll reopen the ticket. Thanks in advance. |
Description:
Currently withCount produces the following query:
But this query seems pretty slow. For example, on our modest dataset of 332 artists and 1287 songs this query takes on average about 0.75 sceonds.
I tried different queries that produce the same result and these run in 0.05-0.1 seconds. Here are the queries:
Could any of these queries be implemented instead of the current or are there some catches as in #18109 ? It seems that soft deletion could still be honored in these queries.
The text was updated successfully, but these errors were encountered: