duckdb · Issues· 894 open

Deterministic bitpacking encoder crash during CHECKPOINT — reproduces across 1.5.2 and 1.6.0-dev12

Parquet reader truncates INT96 timestamps to microseconds; no way to read their nanosecond part

Equivalent argument `ORDER BY` clauses make `LEAD` return different results

`FIRST_VALUE IGNORE NULLS` raises a vector-capacity internal error

`LEAD` advances a sequence too many times

Same query errors before CHECKPOINT and succeeds after it: deleted rows are still counted in cardinality estimates and flip the join order

Incorrect results: hash join silently drops rows when the build side spills to disk

ORDER BY with function gets much slower when combined with LIMIT as function is evaluated for all rows

Qualified count star over asymmetric join miscounts

`min`/`max` on a `DOUBLE` column is ~6x slower than on `BIGINT`, and even ~9x slower in 2.0

Incorrect results: equal VARIANT values report different types depending on whether their row group was shredded

Positional column references can silently reorder macro arguments

list_reduce can use column values from another row

Wrong results from common_subplan when two UNION ALL arms share a join subtree (1.5.1 onward, fixed on 1.6 dev)

disable_parquet_prefetching: v2.0 issues 51x more HTTP requests (33 -> 1,697) and a 2s remote TOP-N becomes 20s