Wrap immutable plan parts into Arc

[askalt]

Which issue does this PR close?

• Closes Wrap more immutable plan parts into Arc #19852

Rationale for this change

Improve performance of query planning and plan state re-set by making node clone cheap.

What changes are included in this PR?

• Store projection as Option<Arc<[usize]>> instead of Option<Vec<usize>> in FilterExec, HashJoinExec, NestedLoopJoinExec.
• Store exprs as Arc<[ProjectionExpr]> instead of Vec in ProjectionExprs.
• Store arced aggregation, filter, group by expressions within AggregateExec.

[askalt]

run benchmark reset_plan_states

[alamb-ghbot]

🤖 Hi @askalt, thanks for the request (#19893 (comment)). scrape_comments.py only responds to whitelisted users. Allowed users: Dandandan, Omega359, adriangb, alamb, comphead, gabotechs, geoffreyclaude, klion26, rluvaton, xudong963, zhuqi-lucas.

[askalt]

@xudong963 could you please run benchmark reset_plan_states?

[xudong963]

run benchmark reset_plan_states

[alamb-ghbot]

🤖 ./gh_compare_branch_bench.sh compare_branch_bench.sh Running
Linux aal-dev 6.14.0-1018-gcp #19~24.04.1-Ubuntu SMP Wed Sep 24 23:23:09 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing askalt/arc_immutable (bb97763) to d90d074 diff
BENCH_NAME=reset_plan_states
BENCH_COMMAND=cargo bench --features=parquet --bench reset_plan_states
BENCH_FILTER=
BENCH_BRANCH_NAME=askalt_arc_immutable
Results will be posted here when complete

[alamb-ghbot]

🤖: Benchmark completed

Details

group     askalt_arc_immutable                   main
-----     --------------------                   ----
query1    1.00     32.2±1.09ms        ? ?/sec    1.01     32.4±0.31ms        ? ?/sec
query2    1.00      9.2±0.08ms        ? ?/sec    1.03      9.5±0.11ms        ? ?/sec
query3    1.00     12.2±0.25ms        ? ?/sec    1.15     14.1±0.08ms        ? ?/sec

[crepererum]

I understand that we wanna avoid breaking changes and hence are kinda liberal with impl Into<...>/impl AsRef<...> parameters. However these methods are generic and will be compiled on the call-site, i.e. whoever calls these methods has to recompile them. Furthermore calling these methods with different types duplicates these methods in LLVM and likely also in the resulting binary. This means: longer compile times and binary size bloat.

Hence I would favor if we could avoid these impl parameters.

[askalt]

I understand that we wanna avoid breaking changes and hence are kinda liberal with impl Into<...>/impl AsRef<...> parameters. However these methods are generic and will be compiled on the call-site, i.e. whoever calls these methods has to recompile them. Furthermore calling these methods with different types duplicates these methods in LLVM and likely also in the resulting binary. This means: longer compile times and binary size bloat.

Hence I would favor if we could avoid these impl parameters.

Actually, I also think that using a generic here isn't justified, since &Vec<u8> can always be converted to a slice. I believe the API should be as simple as possible. Let's get @alamb opinion.