Flow the WITH ORDINALITY struct as a record constructor value

[g31pranjal]

#4650, now merged, added the flowsRecordConstructorValue flag but left every explode flowing the opaque value. This PR turns it on, and only from the SQL layer: LogicalOperator.generateCorrelatedFieldAccess, where an AT unnesting is built, asks for the record constructor. That is the only place that produces an explode with ordinality, and the record-layer constructors keep defaulting to the opaque value, so nothing else changes shape. Wrapping the element of a plain explode in a struct of its own is #4623.

Both shapes stand for the same data and evaluate identically — the plan builds its struct from the protobuf descriptor its declared type names — but the element and the ordinal are now reachable sub-values, which is what lets anything be related to them. The matching that relies on it is #4619; why the shape matters at all is covered in #4650.

What changes in plans

Nothing in fdb-record-layer-core changes, and no core test needed updating. What moves is the expected plan of the five AT queries that also carry an IN: an IN over a value read out of a record is costed differently than one over an opaque value. The movement goes in both directions and is worth a look:

• array-join-at:317, WHERE "at" IN (1, 2): was an explode of the IN list joined with a scan, and is now a single scan with a residual FILTER _._1 + 1 IN @c19. Cheaper.
• array-join-at:305 and in-predicate:402, both IN on the primary key: same operators, but the unnesting moves across the in-join boundary — into the in-join in the first, out of it in the second.
• in-predicate:382 and in-predicate:410, both IN on the unnested value: the IN list explode becomes the outer loop with the table scan inside it, i.e. one full scan per IN element. This is Cost model scores a nested data access the same as an unnested one, so an IN-join can be chosen over a single scan #4621 — the cost model scores a data access nested under an in-join the same as an unnested one.

No index match is lost, and all results still verify. The full :yaml-tests:quickTest has no other plan mismatches.

Compatibility

A plan serialized before the flag existed has it unset, deserializes to the opaque value, and so keeps the shape, and the hash, it was planned with.

The other direction is what gates this PR: a release that predates #4650 does not know the field, drops it, reads the plan as flowing the opaque value, and rejects the continuation. mixedModeTest against 4.15.1.0 — the newest release, cut before #4650 merged — fails all four force-continuation variants of arrayJoinAt and inPredicate with cannot continue query due to mismatch between serialized and actual plan hash for exactly that reason. The same suites pass 12/12 against an external server built from #4650. So this should land only once a release containing #4650 exists.

[github-actions]

📊 Metrics Diff Analysis Report

Summary

• New queries: 0
• Dropped queries: 0
• Plan changed + metrics changed: 2
• Plan unchanged + metrics changed: 0

ℹ️ About this analysis

This automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:

• New queries: Queries added in this PR
• Dropped queries: Queries removed in this PR. These should be reviewed to ensure we are not losing coverage.
• Plan changed + metrics changed: The query plan has changed along with planner metrics.
• Metrics only changed: Same plan but different metrics

The last category in particular may indicate planner regressions that should be investigated.

Plan and Metrics Changed

These queries experienced both plan and metrics changes. This generally indicates that there was some planner change
that means the planning for this query may be substantially different. Some amount of query plan metrics change is expected,
but the reviewer should still validate that these changes are not excessive.

Total: 2 queries

Statistical Summary (Plan and Metrics Changed)

task_count:

• Average change: -11.0
• Median change: -11
• Standard deviation: 0.0
• Range: -11 to -11
• Queries changed: 2
• No regressions! 🎉

transform_count:

• Average change: -1.0
• Median change: -1
• Standard deviation: 0.0
• Range: -1 to -1
• Queries changed: 2
• No regressions! 🎉

transform_yield_count:

• Average change: -1.0
• Median change: -1
• Standard deviation: 0.0
• Range: -1 to -1
• Queries changed: 2
• No regressions! 🎉

insert_new_count:

• Average change: -1.0
• Median change: -1
• Standard deviation: 0.0
• Range: -1 to -1
• Queries changed: 2
• No regressions! 🎉

Significant Regressions (Plan and Metrics Changed)

There were 2 outliers detected. Outlier queries have a significant regression in at least one field. Statistically, this represents either an increase of more than two standard deviations above the mean or a large absolute increase (e.g., 100).

• yaml-tests/src/test/resources/array-join-at.metrics.yaml:196: EXPLAIN SELECT "id", "val", "at" FROM T1, T1."arr1_nn" AS "val" AT "at" WHERE "at" IN (1, 2)
  • old explain: EXPLODE arrayDistinct(@c19) | FLATMAP q0 -> { SCAN([IS T1]) | FLATMAP q1 -> { EXPLODE q1.arr1_nn WITH ORDINALITY | FILTER _._1 + 1 EQUALS q0 AS q2 RETURN (q1.id AS id, q2._0 AS val, q2._1 + 1 AS at) } AS q3 RETURN q3 }
  • new explain: SCAN([IS T1]) | FLATMAP q0 -> { EXPLODE q0.arr1_nn WITH ORDINALITY | FILTER _._1 + 1 IN @c19 AS q1 RETURN (q0.id AS id, q1._0 AS val, q1._1 + 1 AS at) }
  • task_count: 1056 -> 1045 (-11)
  • transform_count: 421 -> 420 (-1)
  • transform_yield_count: 52 -> 51 (-1)
  • insert_new_count: 115 -> 114 (-1)
• yaml-tests/src/test/resources/in-predicate.metrics.yaml:503: EXPLAIN SELECT t.id, n, idx FROM array_table AS t, t.numbers AS n AT idx WHERE idx IN (1, 3)
  • old explain: EXPLODE arrayDistinct(@c23) | FLATMAP q0 -> { SCAN([IS ARRAY_TABLE]) | FLATMAP q1 -> { EXPLODE q1.NUMBERS WITH ZERO BASED ORDINALITY | FILTER _._1 + 1 EQUALS q0 AS q2 RETURN (q1.ID AS ID, q2._0 AS N, q2._1 + 1 AS IDX) } AS q3 RETURN q3 }
  • new explain: EXPLODE arrayDistinct(@c23) | FLATMAP q0 -> { SCAN([IS ARRAY_TABLE]) | FLATMAP q1 -> { EXPLODE q1.NUMBERS WITH ORDINALITY | FILTER _._1 + 1 EQUALS q0 AS q2 RETURN (q1.ID AS ID, q2._0 AS N, q2._1 + 1 AS IDX) } AS q3 RETURN q3 }
  • task_count: 1060 -> 1049 (-11)
  • transform_count: 423 -> 422 (-1)
  • transform_yield_count: 54 -> 53 (-1)
  • insert_new_count: 115 -> 114 (-1)