Avoid DISTINCT on COUNT queries when possible

[chrisyuska]

Motivation / Background

Fixes #55027

When calling .count on an eager-loaded query where the base table belongs_to the eager-loaded table, AR switches COUNT(*) to a COUNT(DISTINCT "id"). However, this is unnecessary as there will never be duplicates in a belongs_to relationship like this.

This isn't normally an issue, but when running COUNT queries on larger tables (at least in Postgres), I've seen this turn ~100ms queries into ~30s queries.

This Pull Request has been created because a very common scenario is paginating data that might have an order clause on an included table, which is then paginated with gems like Kaminari that will call count on the relation without additional reworking of the query. e.g.:

Comment.includes(:post).order(posts: { title: :asc }, comments: { created_at: :desc }).count
# => SELECT COUNT(DISTINCT "comments"."id") FROM "comments" LEFT OUTER JOIN "posts" ON "posts"."id" = "comments"."post_id"

Detail

This Pull Request changes ActiveRecord's Calculation logic around COUNT queries to only add a DISTINCT column when any eager-loaded associations are not belongs_to associations.

Additional information

One workaround we've used is to avoid the eager-load and just change the query to:

Comment.left_outer_joins(:post).order(posts: { title: :asc }, comments: { created_at: :desc }).count

This works fine, but we lose the eager-loaded post association in doing so.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Unrelated changes should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[chrisyuska]

I suspect this PR will need some work before it can be merged. Totally open to alternative approaches or just closing it too if the complexity trade-off isn't worth it.