Area selection aggregation recomputes the same base data several times

[LalitMaganti]

Not an emergency, just tracking it. From a Ctrl-A (all tracks) area selection on
the Android example trace: one selection costs ~11.5s of TP time, much of it
spent materializing and interval-intersecting the same rows more than once.

Each aggregation tab is an independent Aggregator that builds its own
extraction + _interval_intersect_single temp tables. Nothing is shared, so
tabs reading the same base data pay for it repeatedly:

• Thread state (~1.1s wasted): thread_state_aggregation and
  thread_state_by_cpu_aggregation each extract and interval-intersect the same
  utid set. The by-CPU columns are a subset of the main table.
• Sched (~0.2s): cpu_aggregation and cpu_by_process_aggregation do the
  same over the same ucpu set; by-process columns are a subset of by-thread.
• Slice (~1s): slice_aggregation's self-time path and the flamegraph path
  each windowed-extract the same slices. These are genuinely different consumers.

The slowest single query is separate: the slices pivot at 2.6s,
SELECT name, sum(dur), count(1) FROM _viz_slices_for_ui_table ... GROUP BY name.
_viz_slices_for_ui_table (stdlib/viz/slices.sql) is a view built from unions
of thread/process-track joins plus slice JOIN track with track anti-joins, so
GROUP BY name re-derives the whole tree every time and ts+dur > START isn't
sargable, so nothing prunes by time first.

Top offenders from the debug SQL performance view (IN-lists elided):

runtime_ms	query
2668	SELECT name, sum(dur), count(1) FROM _viz_slices_for_ui_table ... GROUP BY name
1920	create or replace perfetto table thread_state_aggregation as ...
829	create or replace perfetto table thread_state_by_cpu_aggregation as ...
822	__temp_dj6be... AS _interval_intersect_single!(..., __temp_597irv...) (slice self-time)
755	__temp_0jnl... AS _interval_intersect_single!(..., __temp_eo1rx...) (slice flamegraph)
590	__temp_o78tb... AS thread_state WHERE utid IN (...) ORDER BY id (by_cpu extract)
590	__temp_k36c3... AS thread_state WHERE utid IN (...) ORDER BY id (thread_state extract)
501	__temp_hulo4... AS _interval_intersect_single!(..., __temp_k36c3...)
494	__temp_tg24f... AS _interval_intersect_single!(..., __temp_o78tb...)
490	create or replace perfetto table cpu_aggregation as ...
417	create or replace perfetto table cpu_by_process_aggregation as ...
358	__temp_597irv... AS slice WHERE track_id IN (...) ORDER BY id
249	__temp_eo1rx... AS slice WHERE track_id IN (...) ORDER BY id

[stevegolton]

I'd say attempting to fix this is a bit of an architectural minefield. This duplication is on purpose in the interest of modularity. Each aggregator is registered and triggers independency. They don't share data.

I'd suggest we to rework the aggregator registration mechanism first if we want to do this. But it necessarily introduces coupling and requires a some careful planning to get the arch right.