v0.5.0

A minor bump rather than a patch, because published numbers move on both suites this covers.

firepanda's ClickBench coverage goes from 42 of 43 to 43 of 43, so its geometric mean and its coverage line in that table are computed over a different set of queries than before. And six TPC-H queries got faster because the firepanda ports stopped carrying columns nobody asked for through joins, so any TPC-H result file written before this is not comparable with one written after it on those six. No other engine is touched by any of it.

firepanda answers all 43 ClickBench queries

q28 groups by a regular expression replacement over the referer, and firepanda had no regular expression engine to run it on, so the driver raised a refusal with the reason on it. firepanda 0.8.6 has one, so the port compiles the published pattern once for the column and runs it, and the refusal list is now empty.

It does not call text_hostname, which is that same pattern written out by hand in Mojo and is faster on it, because answering a benchmark query with a kernel written for that one query measures the kernel and not the engine. Checked against DuckDB 1.5.5 on the 1M partition: two rows, four columns, the same average to every digit, the same count, and the same digest on both text columns.

The number is not good. One run on a loaded laptop put firepanda at 7.1 s against DuckDB's 0.35 s on that query, and it is tracked as tamnd/firepanda#830.

The firepanda TPC-H filters hand all their comparisons over at once

A filter with several comparisons used to and them together two at a time, and every one of those pairwise calls writes a whole mask column for the next call to read straight back. The queries now hand the whole list to one pass. q6 goes 10.3 ms to 8.3 ms, q12 18.1 to 16.6, and q16 and q19 are inside the noise this run could measure.

TPC-H at SF10, all four engines, and the memory ceiling it found

All four answer all twenty two at sixty million line items. firepanda is first on the suite total, 5.18 s against Polars' 7.06, DuckDB's 10.17 and pandas' 98.25, on the least CPU of the three fast engines. It also peaked at 31.57 GB on a machine with 31 GB of RAM, where no other engine went above 25.45, so it was the only one paging and its per query numbers at that size are an upper bound. The cause is that firepanda reads Parquet by handing the file to DuckDB and so holds two copies of the table, which a native reader fixes and no query rewrite will.

The firepanda TPC-H queries project before they join, and take a top n instead of sorting

Five queries were carrying columns through joins that nothing downstream read, and q10 was sorting thirty seven thousand rows to keep twenty. The pandas ports already did this by hand and Polars gets it from its optimizer, so the old code was measuring firepanda doing more work than either.