agent flagged an N+1 on polymorphic associations where per-type queries can't be batched by design

TL;DR

Polymorphic associations store each concrete type in its own table, so fetching N types takes N queries and no single query can replace them. That is the data model working as designed, not an N+1. Verify each type's query is itself batched (one query per type, not per row), confirm the count is constant regardless of row count, then exempt the pattern from the detector.

The query

agent flagged an N+1 on polymorphic associations where per-type queries can't be batched by design

Steps

1. Identify the polymorphic association and its discriminator

Find the association the agent flagged and its type discriminator column (the column that says which concrete type each row is). List the concrete types involved.

Expected: a named polymorphic association, its discriminator column, and the set of concrete types.

2. Check that each type query is batched

For each concrete type, look at the query the ORM issued. The correct pattern is one query per type fetching all rows of that type (typically a single IN query on the type's table). The failure pattern is one query per row within a type.

Expected: queries per type = 1, each carrying the IDs of that type's rows.

3. Confirm the per-request count is constant

Run the request with different row counts (10 rows, 100 rows across the same types). The query count should stay equal to the number of types present, not grow with the row count.

Expected: query count flat as rows scale; it moves only when the set of types changes.

4. Add a polymorphic-association exemption to the detector

Change the detector to recognize the polymorphic pattern (discriminator-based per-type queries, constant count vs row scaling) and exempt it from N+1 alerts. The detector should verify per-type batching (step 2) instead of demanding a single query.

Expected: the same workload re-run produces no alert; a genuine per-row loop inside one type still alerts.

5. Sanity-check the slow path anyway

Exempting the pattern does not exempt it from being slow. Check that the discriminator column is indexed and each per-type query uses its table's index.

Expected: each per-type query hits an index; no sequential scans on large type tables.

Use this when

• The flagged "duplicates" are one query per concrete type of a polymorphic association
• Query count per request equals the number of types, not the number of rows
• The detector demands a single batched query where the schema makes that impossible
• Each type query is itself a batched IN query

Not for this skill when

• One query fires per row within a single type (real N+1, batch per type)
• The association is not actually polymorphic (regular belongs_to flagged wrongly)
• The duplicates are retries, instrumentation queries, or log-line miscounts
• Per-type queries are slow for other reasons (missing indexes)

Variant phrasings

N+1 on polymorphic belongs_to

Same structural answer: per-type queries are required. Verify per-type batching, then exempt.

per-type queries flagged as duplicates

They look similar in text because the tables are siblings. Text similarity is not the test; batchability is.

agent wants one query for all polymorphic types

Impossible by schema design without a cross-table union the ORM does not generate. The detector's expectation is wrong, not the code.

Why it happens

N+1 detectors encode a simple rule: similar queries repeating per request means unbatched fetching. Polymorphic associations break the rule's premise because the repetition is across types, not rows, and the "one batched query" fix the rule assumes cannot exist when each type lives in its own table. The agent applied the rule without checking whether the assumed fix was even expressible.

Edge cases

• Type count growing unbounded: if there is effectively a type per tenant or per user, the constant is large and the pattern deserves a redesign (single-table inheritance or a type-keyed fetch strategy).
• Missing discriminator index: the polymorphic query first fetches the discriminator values; without an index that scan is the real problem.
• Mixed pattern: per-type queries batched correctly but one type lazily loads an association per row. Exempt the polymorphic shape, still fix the inner N+1.
• Single-table inheritance alternative: collapsing types into one table with a type column would allow true single-query fetching, but it trades away per-type schemas. Usually not worth it just to silence the detector.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wHz9nfmjVR9kvQvEPB1owQ