Alternative to ActiveRelationResource which does not produce extra DB queries

まず、include を含むリクエストに対する ActiveRelationResource のキャッシュされないパスを追跡し、ここに示されている 0.9 および 0.10 のクエリログと比較します。追加のリレーションおよび id クエリをキャッシュなしで回避しつつ、含まれるレコードとページネーションの動作を維持する代替案または最適化が実現できれば完了です。

This issue is a (choose one):

• Problem/bug report.
• Feature request.
• Request for support. Note: Please try to avoid submitting issues for support requests. Use Gitter instead.

Checklist before submitting:

• I've searched for an existing issue.
• I've asked my question on Gitter and have not received a satisfactory answer.
• I've included a complete bug report template. This step helps us and allows us to see the bug without trying to reproduce the problem from your description. It helps you because you will frequently detect if it's a problem specific to your project.
• The feature I'm asking for is compliant with the JSON:API spec.

Description

One thing that changed significantly in 0.10 is the introduction of ActiveRelationResource, which seems to be a nice optimization to have when caching is utilized. But when caching is not turned on it actually doubles the amount of DB queries needed to process a request. For example, typical request with include would look something like this in the log on 0.10.x:

DEBUG -- :    (0.0ms)  SELECT "users"."id" AS "users_id", "users"."id" FROM "users" ORDER BY users.id asc LIMIT ? OFFSET ?  [["LIMIT", 10], ["OFFSET", 0]]
DEBUG -- :    (0.1ms)  SELECT DISTINCT users.id AS "source_id", "profiles"."id" AS "profiles_id", "profiles"."id" FROM "users" INNER JOIN "profiles" ON "profiles"."user_id" = "users"."id" WHERE "users"."id" IN (?, ?, ?) ORDER BY profiles.id asc  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :    (0.0ms)  SELECT DISTINCT users.id AS "source_id", "posts"."id" AS "posts_id", "posts"."id" FROM "users" INNER JOIN "posts" ON "posts"."user_id" = "users"."id" WHERE "users"."id" IN (?, ?, ?) ORDER BY posts.id asc  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (?, ?, ?)  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   Profile Load (0.0ms)  SELECT "profiles".* FROM "profiles" WHERE "profiles"."id" IN (?, ?, ?)  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   Post Load (0.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" IN (?, ?, ?, ?, ?, ?, ?, ?, ?)  [["id", 1], ["id", 2], ["id", 3], ["id", 4], ["id", 5], ["id", 6], ["id", 7], ["id", 8], ["id", 9]]
DEBUG -- :    (0.0ms)  SELECT COUNT(*) FROM "users"

Compare to the same request on 0.9:

DEBUG -- :   User Load (0.0ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ? OFFSET ?  [["LIMIT", 10], ["OFFSET", 0]]
DEBUG -- :   Profile Load (0.1ms)  SELECT "profiles".* FROM "profiles" WHERE "profiles"."user_id" IN (?, ?, ?)  [["user_id", 1], ["user_id", 2], ["user_id", 3]]
DEBUG -- :   Post Load (0.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" IN (?, ?, ?)  [["user_id", 1], ["user_id", 2], ["user_id", 3]]
DEBUG -- :    (0.0ms)  SELECT COUNT(*) FROM "users"

Is there a plan to optimize non-cached scenario? Like having an alternative base resource that I'd behave more or less like 0.9 behaved? Thanks.