GC: make sure we are able to GC everything that's GC'able in theory

• GC for hopping windows [SQL] Monotonicity analysis for hopping windows #1889
• GC for tumbling windows
• GC for group operators (LAG/LEAD)
• GC for MIN, MAX
• GC for ARG_MIN, ARG_MAX
• GC for TopK
• GC distinct
• GC antijoin [SQL] There is no GC for antijoins #3390
• GC the internal integral created by linear aggregates.
• GC output traces.  #1920
• AsOf join
  • Support incremental AsOf joins in DBSP #1643
  • Support incremental AsOf joins in the compiler #2009
  • GC for AsOf joins #2010
• GC intermediate joins when computing multiple aggregates over the same relation with lateness and putting the results together in a single relation @mihaibudiu #1919
• GC for nexmark query q9
• Append-only tables RFC: Append-only tables #2040
  • MAX, MIN
  • TOPK
  • JOINS with foreign keys
• WINDOW operators for emit_final views

Explicitly label output views. In a complex program, many of the views may only be used for intermediate results and don't need to be integrated (we also don't need to attach neighborhood circuits to such views). One way to express this would be to explicitly label output views. [SQL] Support LOCAL views, which do not produce circuit outputs #1851

Multiway joins. A multiway join operator will allow us to avoid indexing intermediate results of each pairwise join in a chain. It can be used in multiple contexts, but will make the most difference in queries that compute multiple aggregates, including rolling aggregates.

Implement linear aggregates wherever possible. Linear aggregates use less storage and are more efficient. They are tricky in SQL due to the semantics of NULLs, but can be done according to @mihaibudiu

Optimize away unused columns.