[andygrove]

Which issue does this PR close?

Related to #2652 and #2657.

Rationale for this change

The benchmarking page shows one Ballista column from c76278cd (2026-10-07). The pipelined execution mode in #2657 changes TPC-H SF1000 times a lot, so the page should show it next to the default blocking mode.

What changes are included in this PR?

• benchmarking/index.md: the single Ballista column becomes Ballista blocking and Ballista pipelined, both from one image built at cb49f30f (feat: Add experimental pipelined execution mode (all tasks placed up front, streaming exchange) #2657, on top of main 98d724b3), with DataFusion 55.2.0. The version row is updated to match, and a short paragraph says what the two modes are. The Spark, Comet and Trino columns are unchanged.
• benchmarking/ballista.md: a section listing the settings that differ for pipelined mode (push-staged scheduler and executors, ballista.execution.mode = pipelined), and the commands to reproduce it.

Totals, in seconds (mean of 2 iterations, cold first iteration included):

Ballista blocking	Ballista pipelined	Spark 4.1.3	Spark + Comet 1.1.0-rc2	Trino 483
517.04	278.84	898.17	455.09	411.62

Pipelined is faster on every query, from 7% (q1) to 80% (q14). The blocking column replaces the old 502.43 s from c76278cd, since the page asks for the version, config and results tables to change together.

Why this is a draft

• cb49f30f is on the feat: Add experimental pipelined execution mode (all tasks placed up front, streaming exchange) #2657 branch, not on main, and the pin should be a main commit. When feat: Add experimental pipelined execution mode (all tasks placed up front, streaming exchange) #2657 (and feat: add pipelined exchange operators #2670 under it) merge, I'll rerun both modes at the merge commit and replace the numbers and the pin before this leaves draft.
• The pipelined column can't be reproduced from main until then, and the commands I added for it won't work.

How are these changes tested?

Documentation only. The numbers come from the runs in this comment: same image, cluster (32 executors, 8 vCPU and 64 GiB each, gp3 work-dir) and runner, one suite run per mode. The 22 queries return the same row counts in both modes (q11 returns 0 rows and q13 returns 30 in both). I haven't run a Markdown formatter on the tables.

Are there any user-facing changes?

No.