ROCK-8706 follow-up: remove the three LoadHosts hot operators (guest counts, occurrence N+1, employee scan)

[jwakefield-secc]

TL;DR — how the three fixes relate

All three are variations on one theme: EF6 doing per-attendance-row work over a huge table. But they split into a cousin and a matched pair:

	What EF6 did wrong	The fix
#262 (already merged)	Occurrence filter applied after the GroupJoin, so EF deferred it and ran the member/employee OR over the full 9.4M-row Attendance table	Reorder — narrow by occurrence first
Fix B (guests)	Guest count compiled into a correlated per-row subquery (the ValueAsPersonId UDF, re-run for every row)	Materialize once into a dictionary
Fix C (employees)	Employee set (IQueryable.Contains) compiled into a correlated per-row EXISTS scanning attr-740	Materialize once into an IN-list

Fix B and Fix C are the same bug on two different columns — a correlated subquery that should be a one-time set operation, fixed the same way. #262 was a cousin (a filter-ordering problem, fixed by reordering — not by materializing).

Why three rounds instead of one: #262 removed the full-table scan (the post-#262 plan confirms Attendance is now reached by an IX_OccurrenceId seek), but the two correlated subqueries were underneath it the whole time and became the top of the plan. Note: there's no clean before/after timing for #262 — the pre-#262 statement has aged out of prod Query Store — so this ordering is plan-based, not a measured delta. #262 fixed a real cost; it just wasn't the floor that B and C set, which is why it didn't visibly move the wall-clock. One-liner: #262 stopped scanning the whole table; B and C stop re-running a subquery once per row — the guest half and the employee half of the same remaining problem.

---

Follow-up to #262 (merged). #262 reordered the attendance filters and added AsNoTracking(), which killed the 10–15s member/employee full-table scan. Pulling the actual Query Store execution plan for the surviving 28.7s statement (query_id 29156590) then showed the LoadHosts host-list query still had three hot operators — this PR removes all three.

What the plan showed

For the Project12 host-list query (returns Host = PersonAlias.Person + guest count):

• NonParallelPlanReason="TSQLUserDefinedFunctionsNotParallelizable" — the whole plan was forced single-threaded by the ufnUtility_GetPersonIdFromPersonAliasGuid scalar UDF.
• StatementOptmEarlyAbortReason="TimeOut" — the query was too complex for the optimizer to plan well; cardinality was badly off (1 estimated vs ~185 actual).
• Dominant operator: a correlated AttributeValue scan for AttributeId=740 (~11k rows) rewound per attendance row ≈ 2M row reads, subtree cost 2.42 of 3.01.

Fix A — batch the occurrence lookup (N+1 → 1)

LoadHosts() called AttendanceOccurrenceService.Get() once per active (group, location, schedule) triple. Collapsed into a single query intersected against the exact triple set in memory. Safe because Get(DateTime,int?,int?,int?) is read-only (Queryable().FirstOrDefault(), verified against Rock 1.13.7 source) and IX_GroupId_LocationID_ScheduleID_Date is UNIQUE, so "all matching" ≡ old per-triple FirstOrDefault().

Fix B — decouple the guest-count aggregation

The guest count was folded into the attendance query via GroupJoin; EF6 emitted it as two correlated TOP 1 subqueries over the ValueAsPersonId scalar UDF, rebound per attendance row. Now runs as its own query materialized into a Dictionary<int,int> (~87ms on DEV) and stitched onto each host after the attendance query materializes. This also removes the UDF from the query → unlocks parallelism and simplifies it enough to stop the optimizer timeout.

Fix C — decouple the employee lookup

The member/employee OR left employees.Contains(PersonId) as an IQueryable subquery → the correlated AttributeId=740 scan above. AttributeValue.Value is nvarchar(max) so it can't be an index key (an index can't turn this into a seek). Materializing the ~676 employee person ids once turns the OR into a constant IN-list evaluated a single time, removing the ~2M-row rescan.

Equivalence

Behavior-preserving across all three: same attendance filters, same OrderBy/ThenBy, same per-host guest counts, same employee id set (same AttributeId=740 + Value predicate; null EntityIds filtered — a null could never match a non-null PersonId). RowDataBound's max-guest logic reads GuestCount exactly as before.

Verified on prod/DEV data (read-only):

• Fix A uniqueness invariant — 0 violating rows over 60 days.
• Fix B guest-count equivalence — old correlated-subquery form vs new GROUP BY form diffed to 0 rows, including a busy day (2025-12-30: 46 hosts, 24 of them multi-guest).
• The 28.7s statement confirmed as this LoadHosts query (not LoadPendingCheckins).

[gmcgrady]

Setting up our in-memory HashSets to build a single query later in lieu of multiple round trips via occurrenceService.Get() -- great choice to avoid unnecessary trips to the DB.

[gmcgrady]

Wise to build into dictionary prior to this point, eliminating need to .GroupJoin() in this LINQ query.

[gmcgrady]

Solid pattern of reducing round trips & query complexity by instantiating join-related information in-memory. Assuming tests are clean, this should be good to merge into SEDEV. Approving & merging!