query field cost

Q Can one _summarize grouped on the link reproduce a query field's value for N rows at once, and what do N per-row calls cost?

Endpoint GET /schema/Shot/fields/open_notes_count ; POST /entity/notes/_summarize

Docs claim Silent.

Actual

Shot.open_notes_count: record_count of Note.id
  query {"logical_operator": "and", "conditions": [
    {"path": "note_links", "relation": "is", "values": [{"id": 0, "name": "Current Entity", "type": "Entity", "valid": "parent_entity_token"}]},
    {"logical_operator": "or", "conditions": [sg_status_list is opn, is ip, is rdy]}]}

per row, the first 50 Shots: 50 calls, 14449 ms, median 287 ms, max 328 ms; equals the stored field on 50 of 50

grouped: [note_links, "in", [N Shots]] plus the rest of the tree, grouping [{"field": "note_links", "type": "exact"}]
  N=50   one call 339 ms, 50 groups, agrees with per-row on 50 of 50
  N=300  one call 573 ms, 300 groups, agrees with the stored field on 300 of 300
  group_value on a multi_entity grouping: a list, [{"type": "Shot", "id": <id>, "name": "sh010", "valid": "valid"}]
notes in the project 5944; linked to more than one Shot 0

Teaches

• Rewrite the parent_entity_token leaf from is <row> to in [<every row on screen>], keep the rest of the query, and group on the same path. Each group is one parent's value; a parent with no group is 0 for record_count.
• On the probed site that is 573 ms for 300 Shots against ~87 s for 300 per-row calls, and the cost grew from 339 ms to 573 ms between 50 and 300 rows.
• A multi_entity grouping keys on the whole link list. group_value is a list, and a Note linked to a Shot and a Version lands in a group naming both. Credit a group's value to every parent it names. On the probed site no Note links two Shots, so double-counting under that rule was not observable.
• This covers the aggregating flavours (record_count, sum, count, ...), which group. A single_record field (a sorted row 0, recipe 003) has no grouped form: it stays one _search per row.