Every page render fires unanchored cross-schema queries (access, notifications, threads, mesh_nodes) — ~2 s each over 186 partition schemas

[rbuergi]

Measured from Loki on memex-cloud (namespace memex-cloud, 05:32–06:02Z, 2026-08-29, probe script from the mesh):

716 × [CrossSchema] SLOW … across 186 schema(s)
  mesh_nodes     454 ×  avg 1710 ms  max 7827 ms
  notifications  117 ×  avg 1997 ms  max 4533 ms
  access         113 ×  avg 2055 ms  max 5643 ms
  threads         32 ×  avg 1929 ms  max 3825 ms

PostgreSqlCrossSchemaQueryProvider warns each time: "An unanchored query UNIONs every partition; add a path:/namespace: first segment to pin it to one schema." These fire on ordinary page loads (browser timings: server 40–250 ms, DOM < 1 s, first painted layout area 1.5–2.2 s) — the access and notifications ones look like the permission evaluation and the notification bell, threads the chat thread list, and a large share of mesh_nodes are 0/0-row lookups (misses).

The per-page floor is therefore ~2 s and grows with the partition count. Candidates: anchor the permission/notification/thread queries to the viewer's partition ({user}/…) + the group-grant partitions, cache the access fold per circuit, and stop the Admin/Menu/{X} route misses ([ROUTE] NotFound: No node found at 'Admin/Menu/AI' ×7/30 min per menu key) which each pay a routed lookup.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ETgRRMRVzYMg1WU4pMywed

[rbuergi]

Design direction (Roland, 2026-08-29: "can we issue events so we don't have to poll?"): these three reads should not be per-render queries at all. The mesh is reactive — establish ONE viewer-anchored subscription per circuit at sign-in (notifications, open threads, effective permissions, anchored to {user}/… plus the partitions the viewer's group grants name) and let the change feed update it; a page render then reads a warm stream instead of UNIONing 186 schemas. The Admin/Menu/{X} route misses belong to the same change: resolve the menu keys once per circuit, not per render.

[rbuergi]

🚨 First: the log line this issue is built on cannot tell fan-out from slowness

Before the enumeration, a correction to the evidence — because it changes what the 716 lines mean.

PostgreSqlCrossSchemaQueryProvider.LogFanOutTiming printed _cachedSchemaCount — the width of the last GetSearchableSchemasAsync result — as "across {N} schema(s)", and appended "An unanchored query UNIONs every partition; add a path:/namespace: first segment to pin it to one schema" unconditionally, on every line.

That field is written in exactly one place, and the partition-pinned fast path never reaches it — pinning exists precisely to skip that round trip:

var pinned = ResolvePinnedPartition(parsed, ResolveGlobalSchema);
if (pinned is not null)
{
    schemas = [pinned];        // ← no SyncSearchableSchemas, no GetSchemasWithTable

So a pinned, single-schema query that merely ran slowly logged, verbatim, as a 186-partition fan-out with a fan-out diagnosis attached. The LogInformation line one screen up already logged schemas.Count correctly — the two lines contradicted each other about the same query, and only the wrong one is visible at default level.

This matters most for the biggest bucket in the issue. "A large share of mesh_nodes are 0/0-row lookups (misses)" is the exact shape of a routed path probe: PathResolutionService resolves Admin/Menu/AI as path:"Admin/Menu/AI"|"Admin/Menu"|"Admin", which pins to schema admin and finds nothing — and this issue separately counts those very probes. Under the old line those are indistinguishable from a real 186-branch UNION.

To be explicit about what I am and am not claiming: I am not saying the 716 lines were all pinned — that cannot be recovered from the logs, which is the whole problem. I am saying the line could not distinguish the two, so 716 × 186 schemas is not a measured quantity. Fixed in Systemorph/MeshWeaver.Plugins#854, which also makes a narrowing readable as across 3 of 186 at default level (today the only witness for Systemorph/MeshWeaver.Plugins#983/#843 is a LogDebug line that is off in production).

---

The enumeration: every query a signed-in page render fires

Anchored = carries a concrete, non-wildcard first path:/namespace: segment, so ResolvePinnedPartition pins it to one schema. "Cached" = goes through GetQuery, whose upstream is process-wide Replay(1).AutoConnect(1); "uncached" = a bare IMeshService.Query, which is a pass-through and opens a fresh subscription every call.

A. Portal shell — every page

#	Query	Where	Anchored	Frequency
1	nodeType:Notification sort:CreatedAt-desc	NotificationCenter.razor:44	❌ no anchor, no limit	uncached, per circuit
2	same literal again	NotificationCenterPanel.razor:246	❌	uncached, per panel open — a second independent fan-out
3	nodeType:NodeType select:…,content	CompileProgressIndicator.razor.cs:93 via LayoutAreaView.razor:10	❌	cached (nodetypes-compiling), once per process, held live forever
4	nodeType:UiContribution	UiContributionCatalog.cs:95	❌	one subscription per silo
5	Admin/Menu/{context} point read	MenuPresentationOverlay.cs:44	✅ (admin)	per context × per area render
6	IsGlobalAdmin() + Timeout(5s)	UserProfile.razor.cs:110 (OnParametersSetAsync)	—	per shell re-render

#1 is the notifications bucket. It fetches every notification row in the mesh the viewer can read, with no limit:, and reduces it to a badge count client-side. It is the only render-path query here that is both unanchored and uncached.

#5 is fixed in #2651 — it is anchored, but it point-reads a node that is absent by design, so every probe costs a [ROUTE] NotFound + a DeliveryFailure NACK, and RenderMenus is a global WithRenderer(_ => true, …) predicate renderer that reinstalls it via ReplaceDisposable on every area render, per context. Contexts are data-driven (UiContributionCatalog), so each plugin that declares a TopBar menu adds one more permanently-missing lookup to every area render on the mesh.

#6 is not a query cost but is worth its own look: for a NON-admin, .Where(x => x) never emits, so the render waits out the full 5 s timeout on every shell re-render (and PortalLayoutBase pumps StateHasChanged six times). That is a plausible contributor to "first painted layout area 1.5–2.2 s" that has nothing to do with Postgres.

B. The permission fold — every access check on every render (PermissionEvaluator)

#	Query	Anchored	Frequency
7	nodeType:Role scope:subtree … limit:all	❌	cached $security-roles, once per process
8	nodeType:GroupMembership scope:subtree … limit:all	❌	cached $security-memberships — gates every permission emission (it sits inside the CombineLatest)
9	nodeType:{gatedType} scope:subtree … limit:all	❌	cached, one per gated NodeType
10	namespace:{scope}/_Access nodeType:AccessAssignment …	✅	cached per ancestor scope — depth+1 new queries per new path visited
11	root leg of 10: namespace:_Access …	✅ if _Access is registered as a global satellite (→ system_access); otherwise ❌	cached
12	namespace:{scope} id:_Policy nodeType:PartitionAccessPolicy …	✅ per scope; root leg is namespace: (empty) → ❌	cached

Two amplifiers on top, neither a new query but both multiplying the fold:

• For every non-anonymous user the fold recursively re-evaluates itself as Public and ORs the result (PermissionEvaluator.cs:237-240).
• WrapWithPerUserRls runs one CheckPermission(node.Path, Read) per node per snapshot, uncached — so a large synced-query result is a large number of folds.

7–9 are unanchored by design and documented in SecurityQueries: a GroupMembership lives under the group node, which may sit in a different partition than the grant naming it. Left alone.

C. Home page /{user}

#	Query	Anchored	Frequency
13	nodeType:AccessAssignment content.accessObject:{ownerId} (ObserveSharedTargets)	❌ (table access)	uncached — a fresh fan-out per home render
14	namespace: (empty) leg of FirstLevelUnion	❌ (root rows exist in every schema)	per home render
15	namespace:{ownerId} … leg	✅	per home render
16	path:{owner}/_App scope:children nodeType:App (Apps band)	✅	per home render
17	path:{a}|{b}|{c} (Shared / Pinned bands)	⚠️ pins to Paths[0] only — see below	per home render

#13 is the access bucket, and the asymmetry is the tell: the identically shaped read on the identity path (OnboardingMiddleware.LoadUserRoles, nodeType:AccessAssignment content.accessObject:"{u}" scope:subtree) is cached process-wide under auth:userRoles:{username}; the home's is a bare mesh.Query and re-runs on every render.

D. Chat side panel — per mount

#	Query	Anchored	Frequency
18	nodeType:Thread content.createdBy:{u} sort:LastModified-desc select:…	❌ (table threads)	cached my-threads / resume-threads
19	namespace:{path} scope:descendants nodeType:Thread	✅	cached per path
20	agent picker namespace:A|B|C nodeType:Agent …	✅ as of Plugins#843	cached

#18 is the threads bucket, and it is legitimately cross-partition — ThreadQueries documents why: a thread lives at {contextPath}/_Thread/{id} for whatever node it was started from, so "my threads" is not scoped to any partition. Left alone. (Note OwnedBy is a content filter, not an anchor — it narrows rows, not branches.)

E. Identity / request pipeline

#	Query	Anchored	Frequency
21	nodeType:User (UserIdentityCache.DirectoryQuery)	❌ literally, but pinned in practice by the nodeType:User → auth routing hint	once per process
22	nodeType:AccessAssignment content.accessObject:"{u}" scope:subtree limit:all	❌	cached per username — one fan-out per user per process
23	nodeType:User content.email:{email} limit:1	❌	cached per email, but its own comment notes that for a genuinely-not-onboarded user "this path runs on every request"

Dead code (fires never)

ChatHistorySelector.razor:236 — nodeType:Thread createdBy:{userId} — is unanchored and filters on the envelope createdBy:, which PostgreSqlStorageAdapter.AuthorCols projects as NULL::text for satellite reads, so it can never match a row. The component is referenced nowhere in either repo. Worth deleting, but it costs nothing today.

---

What I fixed

• Systemorph/MeshWeaver.Plugins#854 — the fan-out log reports this query's branch count and only advises anchoring when there is a fan-out. 11 pure tests, mutation-verified (reverting to the cached field fails exactly the 5 new ones).
• perf(menu): read the menu catalog with the storm-safe existence query, not a point probe #2651 — Get rid of project dependencies in NotebookEditorControl #5 above: the menu catalog is read with the storm-safe existence GetQuery instead of a point probe. 19 tests incl. a source guard; full MeshWeaver.Graph.Test green (1717).

What I deliberately left, and why

• Add entire company to Open SMC Teams #1 / Test #2 the notification bell. Cannot be anchored as written: notifications are created at {mainNodePath}/_Notification/{id} where mainNodePath is the entity the notification is about (a thread, Admin, a user root), and Notification carries no recipient field — visibility is pure RLS. Anchoring needs a per-user inbox ({user}/_Notification), which is a data-model change, not a query rewrite. The cheap half is available now and I did not take it either: it is IMeshService.Query, so every circuit opens its own; routing it through GetQuery (as the thread list two files over already does) would collapse it to one live subscription per process. I left it because that read is unbounded and WrapWithPerUserRls folds permissions per node per snapshot, so I could not convince myself the consumer-side cost is smaller than the fan-out it removes — that needs a measurement I cannot take from outside the VNet.
• Update release-packages.yml #13 the home's cross-partition grant read. Genuinely cross-partition (Inconsistent visibility for private/invited users: inaccessible nodes listed in 'last edited', invited module missing from navigation, search and access menu expose users #385). The safe-looking fix — route it through GetQuery like its twin on the identity path — moves the read from source-side RLS (user_effective_permissions) to consumer-side PermissionEvaluator, and AccessControl.md is explicit that those are two independent implementations that must agree. A divergence would silently change what "Shared with me" shows. Not something to land without a test that runs both.
• [Snyk] Upgrade monaco-editor from 0.32.1 to 0.45.0 #7–9 the security fold's global legs, Update release-packages.yml #18 threads, Determine back-end contributors #3/Clarify license options with ag grid #4 the NodeType and UiContribution catalogs. Cross-partition by construction, each documented at the call site.
• Update release-packages.yml #14 the empty-namespace home leg. Root-level rows genuinely live one per schema. Worth noting for later: public.top_level_index is a matview of exactly this set, already access-filtered by public.partition_access, and AutocompleteTopLevelAsync answers from it with one indexed read and no fan-out. Serving the home's root leg from it is a real lever — but it would have to reproduce is:main, is:content, -nodeType:User, the sorts and source:accessed, so it is a piece of work, not a patch.
• Update release-packages.yml #17 path:A|B|C. QueryParser sets Paths = values and Path = values[0]; both MeshQuery.MergeQueryNamespaces and ResolvePinnedPartition read only Path. When the members live in different partitions — which is exactly the case for the home's "Shared with me" band — the query pins to the first member's partition and the rest silently return nothing. That is docs: plugin roots are Store/Plugin + PluginContent, not a Space/PluginManifest root #844, and I would re-read it as a correctness issue (silent row loss) rather than a perf one.

Is this one defect or two, with #2641?

Two — but coupled in one direction, and #2641 is the amplifier.

• Every page render fires unanchored cross-schema queries (access, notifications, threads, mesh_nodes) — ~2 s each over 186 partition schemas #2640 is query shape and caching on the render path: what is asked, how wide, and how often. Nothing in it depends on the transport.
• SynchronizationStream frame loss storm (847 re-requests / 30 min) and UserIdentityCache still failing after #2605 on memex-cloud #2641 is stream transport (frame loss / re-request, cross-pod stream routing) plus a separate data defect in UserIdentityCache (see my comment there).
• The coupling: every per-circuit subscription in section A above is re-established on reconnect. SynchronizationStream frame loss storm (847 re-requests / 30 min) and UserIdentityCache still failing after #2605 on memex-cloud #2641 records 33 circuit-DOWN events in 30 minutes for one interactive user; each one re-runs the bell's uncached, unbounded, mesh-wide notification read and re-mounts the chat panel. So circuit churn multiplies this issue's per-circuit costs.

Fixing either does not fix the other, and neither should be closed as a duplicate. The ordering that follows: #2641's circuit churn first, because it is a multiplier on whatever this issue's per-circuit reads end up costing — and because a fix here measured while circuits are still cycling 33×/30 min will not read cleanly.

Measured vs inferred

Measured (Azure Monitor, memexaks-pg, read-only, hourly to 2026-08-29T07:00Z): daytime hours 20.5–71.3% mean with every hour peaking 97–99%; overnight 2026-08-28 23:00Z–2026-08-29 04:00Z at 3.8–5.5%. Load is entirely user-driven.

Measured from source (all of it verifiable by reading the named file): every anchored/unanchored classification above; the caching behaviour of each call site; that LogFanOutTiming read a field the pinned path never writes; that RenderMenus is a _ => true renderer using ReplaceDisposable; that path:A|B|C pins to Paths[0].

Inferred, and not proven: which queries produced which of the 716 lines. Metrics and that log line cannot name a statement, and the line as written could not distinguish a pinned query from a fan-out at all. The per-bucket attributions above ("#1 is the notifications bucket") are shape-matching — the only render-path query that hits the notifications table is #1, and so on — not a trace. Confirming them needs pg_stat_statements or the corrected [CrossSchema] lines from Plugins#854 once it is deployed.

🤖 Generated with Claude Code

[rbuergi]

Roland's acceptance shape for the home/apps first paint (2026-08-29): "ONE mesh query first to get all WITHOUT content. Then pre-render this — this is fast. In a second stage, replace by real icon with overlay and stuff."

The Apps band itself already conforms (single-partition contentless query, row-painted, stage-2 target/content resolution bounded and in-place — UserActivityLayoutAreas.BuildAppsBand + MeshSearchView.RowOnlySelect). What breaks the experience is everything AROUND the band on the render path: the bell/threads/permission-fold cross-schema queries and the circuit handshake put a ~2 s floor before ANY area paints. So the fix here should be held to that standard: the first paint of a page must need exactly one anchored, contentless query for its primary surface; every enrichment (icons from content, thumbnails, overlays, counts) arrives as a later in-place update, never as a gate on first paint.

[rbuergi]

Scoping the four tables — and a warning about the one that is core's

Measured on origin/main today, because "anchor the queries" is only right for some of them and actively wrong for at least one.

The access query in core is unanchored BY NECESSITY — do not anchor it

UserActivityLayoutAreas.ObserveSharedTargets issues:

mesh.Query<MeshNode>(MeshQueryRequest.FromQuery(
    $"nodeType:AccessAssignment content.accessObject:{ownerId}"))

No path:, no namespace: — so it UNIONs every partition schema, and it matches the access line in the measurement above (113 × avg 2055 ms).

🚨 It cannot be anchored to the viewer's partition, and anchoring it would be a silent data-loss bug rather than a slow query. A share grant lives in the granting partition, not the grantee's — that is what makes it a share. Pinning this to {user}/… would return only the grants a user made to themselves, so every item shared with them would vanish from their activity view, with no error and no empty-state distinguishable from "nothing is shared with me".

That places it squarely in the class #2503 calls "the genuinely unanchored", whose only lever is provider-side — skip empty schemas (#2503 item 2, in MeshWeaver.Hosting.PostgreSql, i.e. MeshWeaver.Plugins). A caller-side fix does not exist for this one.

The core query that looked like a candidate is already anchored

NotificationService's settings lookup — the obvious suspect for the notifications line — already pins:

.GetQuery($"{NotificationSettingsNodeType.NodeType}|{path}",
    $"path:{path} nodeType:{NotificationSettingsNodeType.NodeType} select:path,id,namespace,name,nodeType,content")

So the notifications fan-out is not this call site. It is the bell's own listing, which lives in the portal chrome — MeshWeaver.Plugins.

Where each of the four actually lives

table	owner	anchorable?
access	core (ObserveSharedTargets)	❌ no — see above; needs empty-schema skipping
notifications	Plugins (portal chrome / bell)	likely yes, to the viewer
threads	Plugins (AI engine)	likely yes, to the viewer
mesh_nodes	mixed; a large share are 0/0-row misses	the Admin/Menu/{X} route misses named in the body are the cheap half

What this changes about the issue

The body's remedy — "anchor the permission/notification/thread queries to the viewer's partition" — holds for three of the four and is wrong for access. Worth fixing in the issue text before someone implements it as written: the failure mode of getting this wrong is invisible (shares silently disappear), which is exactly the kind that survives review.

The 2026-08-29 acceptance shape is unaffected and still the right bar: one anchored, contentless query for the primary surface, every enrichment arriving as a later in-place update, never as a gate on first paint.

[rbuergi]

Re-triage against current main: one candidate is already done, one cannot be done the way this issue proposes

Checked each of the four candidates against main rather than against the measurement. Two of them have moved.

1. Admin/Menu/{X} route misses — fixed, 50 minutes after this measurement closed

The window here is 05:32–06:02Z on 2026-08-29. The fix is 83b1892be, "perf(menu): read the menu catalog with the storm-safe existence query, not a point probe", committed 06:52:49Z the same morning. So the misses in this data are real and are also already gone.

MenuPresentationOverlay.CatalogStream now uses an anchored workspace.GetQuery(...) on path:Admin/Menu/{context}, and its comment names this issue. Worth striking from the candidate list so nobody re-derives it — and worth noting why it was expensive, because the reasoning generalises: RenderMenus is a global predicate renderer, so it ran once per menu context per area render, and contexts are data-driven, meaning installing a plugin that declares a TopBar menu added one more permanently-missing routed lookup to every render on the mesh.

2. Notification settings reads — already anchored

NotificationService (line 149) and NotificationSettingsNodeType (line 72) both read through GetQuery with a concrete path:{path}. So whatever the 117 notifications cross-schema hits are, they are not these — and I could not find a bell/unread query in core at all, which suggests that population originates outside this repo. Worth confirming before anyone optimises core for it.

3. 🚨 access cannot be anchored — the root scope has no partition, by construction

This is the one that changes the shape of the work. From SecurityQueries itself:

"Anchored reads are normally served by a single partition's delegate, but the ROOT scope's anchor (_Access / the empty namespace) resolves to no partition and falls through to the same cross-schema fan-out."

So "add a path:/namespace: first segment" — the provider's own warning text, and this issue's first candidate — is not available for the root-scope leg. There is no partition to name.

And the second obvious lever is worse than unavailable, it is dangerous. Every fold query goes through SecurityQueries.Enumeration, which overwrites any limit: rather than honouring it, deliberately:

"A group-scoped deny … is applied only to the viewers the membership read says are in that group — so the same truncation makes a revocation FAIL OPEN, leaving a viewer reading content the deny was written to take away."

So paging the access fold re-opens a security hole. Neither anchoring nor paging is on the table.

That leaves caching — this issue's third candidate — as the only lever, and it inherits the same hazard from the other side: a cached fold that does not invalidate on a grant or membership change serves a revoked viewer their old permissions. So the work is not "cache the fold"; it is "cache the fold with an invalidation seam the change feed drives", which is a materially bigger and more delicate change than the issue's one-line candidate suggests. I would not want someone to pick this up believing it is a memoisation.

I have not looked at threads (32×) or the remaining mesh_nodes (454×).

Suggested restatement

The per-page floor is real and the measurement is good. But as written the issue reads as four similar optimisations, and it is not: one is done, one is probably not in this repo, and one is a security-sensitive caching design. Re-measuring on current main before starting would also say how much of the 716 the menu fix already removed — mesh_nodes misses were called out as "a large share", and permanently-missing menu lookups are exactly that shape.

[rbuergi]

2026-08-31: root cause sharpened — the fan-outs are a LOCK bomb, and the callers are now named

Live pg_stat_activity sampling from inside the systemorph portal (evening load, the #2895 rebake writing concurrently): every slow query was waiting on LWLock/LockManager, the rebake's INSERT … ON CONFLICT sat in Lock/relation blocked by four fan-out SELECTs, and pinned point-reads waited 2–5 s as innocent victims. One 188-schema UNION ALL takes heavyweight locks on ~500+ relations; past 16 fast-path slots per backend everything goes through the shared lock manager, and a handful of concurrent fan-outs seize the whole database. So this issue's ~2 s floor and the 08-31 "portal completely unresponsive" wedges (memex ~18:30Z: 399 SubscribeRequest 60 s timeouts/40 min, Store/Plugin hub starved, /api/plugins 503) are one defect.

Callers now NAMED (closing this issue's open populations):

• notifications (117×, 2 286–4 203 rows/query) = the notification bell + panel — NotificationCenter{,Panel}.razor in MeshWeaver.Plugins fire bare nodeType:Notification sort:CreatedAt-desc, unanchored, unbounded, LIVE (re-queries on matching change — which is how the rebake write storm multiplied it). Confirms the earlier triage's suspicion that this population is not in core.
• access + part of mesh_nodes = SecurityQueries globals (Roles, Memberships, GatedNodes per gated type, root-scope _Access/_Policy) — unanchored by construction, per this thread's earlier triage.
• One node_type ILIKE $1 shape seen live, caller not yet named — identifiable in one Loki query once Plugins#1035 (the SLOW line now carries the query shape) deploys.

Maintainer directive (Roland, tonight): eliminate the fan-outs entirely — no render-path query may UNION every partition. The census + measured mechanism + per-caller elimination plan (recipient-partition notification delivery; a write-maintained public materialization of the fold's global sets on the partition_access precedent; a ratchet on the shape log) is conserved as Doc/Architecture/CrossSchemaFanOutElimination — PR #2920.

[rbuergi]

Live census from memex-cloud — 1,030 fan-outs, 38 minutes of cumulative wall time, in one log window

Sampled the running portal's own [CrossSchema] SLOW lines (kubectl logs --tail=6000, memex-cloud, 2026-09-01 14:21Z, image 3.0.0-rc9.ci.7231). This turns the plan in Doc/Architecture/CrossSchemaFanOutElimination into a priority order measured on production rather than an inventory.

hits	avg	max	table :: query
293	1885 ms	4835 ms	access :: nodeType:AccessAssignment path:- scope:Exact
172	2279 ms	5785 ms	access :: nodeType:AccessAssignment path:- scope:Subtree
141	2310 ms	5480 ms	threads :: nodeType:Thread path:- scope:Exact
114	2268 ms	5853 ms	notifications :: nodeType:Notification path:- scope:Exact
44	2036 ms	2272 ms	mesh_nodes :: nodeType:Agent path:- scope:Exact
39	2536 ms	5876 ms	mesh_nodes :: nodeType:Store/Plugin path:- scope:Exact
37	2580 ms	6487 ms	mesh_nodes :: nodeType:Email path:- scope:Exact
34	2647 ms	6278 ms	mesh_nodes :: nodeType:PartitionAccessPolicy path:- scope:Children

Totals: 1,030 slow fan-outs, 2,272.9 s (~38 min) of cumulative query wall time in one window.

Three things the numbers say that the inventory did not

1. access is the single biggest cost, not the notification bell. 465 of 1,030 hits (45%) are AccessAssignment, split across scope:Exact and scope:Subtree. The bell (Notification, 114) is fourth. The bell is still worth fixing — it is live and re-queries on every matching write, which is a different and worse property — but if the ordering is by cumulative cost, the security fold leads by a wide margin.

2. Every one of these carries path:- — no anchor at all. Not a too-broad anchor: absent. That matters for the fix, because it means these are not queries that need narrowing so much as call sites that never supplied a path. It also makes them cheap to find: grep the callers that build a query with an empty path segment.

3. They return nothing. The lines read 0/0 rows across 192 of 192 partition schema(s). Every one of the 34 PartitionAccessPolicy fan-outs I read in full took 1.1–6.3 s to answer zero rows over all 192 schemas. So this is not a case of an expensive query doing useful work — the whole cost is pure waste, which is the strongest possible argument for elimination over optimisation.

Why this is the wedge mechanism, not just latency

Consistent with the 2026-08-31 pg_stat_activity finding already on this issue: a 192-schema UNION takes 500+ relation locks against 16 fast-path slots, so these park on LWLock/LockManager and writes queue behind them. At 293 hits averaging 1.9 s for one query shape, the lock pressure is close to continuous. That is the same mechanism as the portal-unresponsive wedges, which is why "eliminate, don't optimise" is the right directive.

Caveats on this measurement

• One window on one deployment, from the tail of the log buffer — the absolute counts scale with window length and traffic, so treat the ranking and the per-query costs as the signal, not the totals.
• The portal is running ci.7231 (built 06:05:49Z), roughly 8 h behind ci.7370. Anything merged today is not reflected.
• I did not attribute these to specific call sites. path:- should make that mechanical, and the top four cover 72% of the hits.

[rbuergi]

🚨 Re-measured on origin/main: the first suggested fix is a security regression, and core says so

This issue proposes "anchor the permission/notification/thread queries to the viewer's partition
({user}/…) + the group-grant partitions". The access fan-out is the biggest of the four
(113 × avg 2055 ms), so that is the natural place to start — and it is the one that must not be
done that way.

PostgreSqlCrossSchemaQueryProvider itself is no longer in this repo (the storage backends left in
the carve-out; core contains no MeshWeaver.Hosting.{PostgreSql,Cosmos,Snowflake,Sqlite} project).
But the queries it serves are written in core, in
src/MeshWeaver.Mesh.Contract/Security/SecurityQueries.cs — "the ONE place the permission-deciding
mesh queries are written" — and its own header explains why several of them are deliberately
unanchored:

Several of these reads are GLOBAL by necessity — a GroupMembership lives under the group node,
which may sit in a different partition than the grant that names the group, so the query carries
no path: and no namespace:.

And what it costs to get this wrong is spelled out one paragraph further down (#2011):

a truncated membership list is indistinguishable from "this viewer is in no groups", so a
group-derived permission simply vanishes and every surface gated on it disappears at once — with
nothing logged and nothing failing … the same truncation makes a revocation FAIL OPEN, leaving
a viewer reading content the deny was written to take away.

Anchoring the membership read to the viewer's partition has exactly the effect of truncating it: a
membership record living in the group's partition is not in the viewer's, so it is not returned.
The permission silently vanishes in one direction and a group-scoped deny silently stops
applying in the other. Nothing goes red either way — which is the same "no result and not allowed
are the same value" failure the file exists to prevent.

What this does NOT rule out

The perf problem is real and the measurement stands. What it constrains is which of the four
fan-outs can be anchored, and how:

• mesh_nodes — the issue notes a large share are 0/0-row lookups (misses), and separately the
  Admin/Menu/{X} route misses ([ROUTE] NotFound: No node found at 'Admin/Menu/AI' ×7/30 min per
  key). Those are not permission reads and are the cheapest honest win.
• notifications / threads — the bell and the thread list. Neither decides a permission, so
  anchoring them is a scoping question, not a correctness one.
• access — anchoring is off the table for the reads SecurityQueries marks global. The
  tractable direction here is the one the issue lists second, cache the access fold per circuit,
  which changes how often the global read happens rather than what it returns.

Worth stating explicitly on the issue because the four fan-outs look interchangeable in the Loki
output, and they are not: three are a cost, one is a correctness boundary.

(Measured while sweeping the core backlog; no code change made. The provider-side half belongs in
MeshWeaver.Plugins now.)