pub const VECTOR_SIZE: usize = 8192;Expand description
How many values are in a full vector.
8192, which is four times DuckDB’s 2048 and eight times what this was. It started at 1024 for
three reasons: the FastLanes unit is 1024, a validity mask comes out at exactly 16 u64 words,
and a vector of 16 byte string views is 16 KiB, which is small enough that several of them sit
in L1 at once. The first two are still true of any multiple of 1024. The third was the argument
and it was an argument about the wrong level, because it was also deciding how much of a table
one zone map covered and how much work one call into the pipeline did, and those wanted a much
larger number than L1 did.
#984 separated them: a table in memory is stored in row groups of 122,880 rows now and a chunk
is a window into one, so the vector size is only the execution unit and is free to be chosen for
what an operator costs per call. #480 measured it. On twenty million rows in memory, one thread,
going from 1024 to 8192 takes count(*) with a filter from 14.0 milliseconds to 1.9, sum(v)
with the same filter from 39.6 to 29.6 and sum(k + v) from 66.8 to 52.6. On ClickBench over
Parquet, where the time is decode and hash aggregation rather than per call overhead, the same
move is worth about eight percent on the total of the twenty nine queries that run.
32768 was measured too and is not better: it wins another few percent on the full scans and loses on the load, on a needle that the chunk zone maps would otherwise prune, and on anything with a string column, where a vector of views is half a megabyte. 8192 is where the per call overhead has stopped mattering and the working set has not started to.