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
Grouped query performance of total_count using SQL #1023
base: master
Are you sure you want to change the base?
Conversation
This test's data was built using a hash keyed by a name which was included twice, so it would always pass as long as total_count builds a valid query. Fixed by using a 2D array instead.
Improved performance for total_count on grouped ActiveRecord::Relation. This re-implements kaminari#979 using plain SQL to avoid issues kaminari#1012 and kaminari#1015
I think we should prefer #1022 to keep benefit of prepared statements. See #979 (comment) |
I'm more than happy to ditch this in favour of the Arel solution. |
I just want to see if this version succeeds with activerecord 4.2 where #1022 does not. |
Only count non-null values of column_name if supplied. This meets the semantics of the SQL count function without requiring that column_name is one of the grouped columns. Also use the older-style heredoc syntax for backwards-compat.
...and it looks like activerecord 4.1 returns string representations from `select_value`
activerecord 4.1 doesn't like the use of a numeric value for `select`
Finally passing the tests. @guigs would you consider a SQL-based solution given that the Arel solution is not backwards-compatible with activerecord < 5? The raw SQL in this PR is functionally identical to the Arel-built query, and tbh I don't see how prepared statements factor into it, because the query is built, run and discarded immediately. |
Improved performance for total_count on grouped ActiveRecord::Relation.
This re-implements #979 using plain SQL to avoid issues #1012 and #1015
This is an alternative solution to #1022