Alternative to ActiveRelationResource which does not produce extra DB queries

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.

Start by tracing ActiveRelationResource's uncached path for requests with include and compare it with the 0.9 and 0.10 query logs shown here. Done means an alternative or optimization avoids the extra relation and id queries without caching while preserving included records and pagination behavior.