- C++ 77.9%
- sql 16%
- Python 2.6%
- C 2.5%
- Swift 0.4%
- Other 0.4%
30c64e17ecMATCH_RECOGNIZE contains a complexity [boobytrap](https://youtu.be/aDoorU4X6Jk?t=2051) as specified by ISO with exponential(!) complexity. Consider this query: ```SQL SELECT count(*) FROM (VALUES(1),(2),(3),(4),(5),(6),(7),(8),(9),(10)) x(y) MATCH_RECOGNIZE ( ORDER BY y MEASURES 1 AS m PATTERN ((CALM | DOG | SIPS | TEA | HIS | SMALL | HOME | BURNS | QUITE)* HOT) DEFINE HOT AS HOT.y < avg(CALM.y) - avg(DOG.y) ); ``` with only 10 rows of input, this takes more than 5 mins to finish on DBMS X & Trino (and DuckDB, before this PR). The computational complexity is `O(m^n)` where `n` is the number of rows(!) and `m` is the number of pattern variables in the inner parens. This PR adds a new setting `match_recognize_max_states` that limits the matching steps. If exceeded, the following message is now shown: > MATCH_RECOGNIZE gave up on a match after exploring 1000000 states. A DEFINE condition here reads the match itself and not only the row it tests, so the matcher has to keep the different ways of matching the same row apart, and their number grows quickly with the size of the partition. Narrow the PATTERN or the DEFINE conditions so that fewer ways reach the same row, or raise match_recognize_max_states. |
||
|---|---|---|
| .github | ||
| api_spec | ||
| benchmark | ||
| data | ||
| examples | ||
| extension | ||
| logo | ||
| scripts | ||
| src | ||
| test | ||
| third_party | ||
| tools | ||
| .clang-format | ||
| .clang-tidy | ||
| .clangd | ||
| .codecov.yml | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .sanitizer-leak-suppressions.txt | ||
| .sanitizer-thread-suppressions.txt | ||
| AGENTS.md | ||
| AI_POLICY.md | ||
| CITATION.cff | ||
| CLAUDE.md | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| DuckDBConfig.cmake.in | ||
| DuckDBConfigVersion.cmake.in | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
DuckDB
DuckDB is a high-performance analytical database system. It is designed to be fast, reliable, portable, and easy to use. DuckDB provides a rich SQL dialect with support far beyond basic SQL. DuckDB supports arbitrary and nested correlated subqueries, window functions, collations, complex types (arrays, structs, maps), and several extensions designed to make SQL easier to use.
DuckDB is available as a standalone CLI application and has clients for Python, R, Java, Wasm, etc., with deep integrations with packages such as pandas and dplyr.
For more information on using DuckDB, please refer to the DuckDB documentation.
Installation
If you want to install DuckDB, please see our installation page for instructions.
Data Import
For CSV files and Parquet files, data import is as simple as referencing the file in the FROM clause:
SELECT * FROM 'myfile.csv';
SELECT * FROM 'myfile.parquet';
Refer to our Data Import section for more information.
SQL Reference
The documentation contains a SQL introduction and reference.
Development
For development, DuckDB requires CMake, Python 3 and a C++17 compliant compiler. In the root directory, run make to compile the sources. For development, use make debug to build a non-optimized debug version. You should run make unit and make allunit to verify that your version works properly after making changes. To test performance, you can run BUILD_BENCHMARK=1 BUILD_TPCH=1 make and then perform several standard benchmarks from the root directory by executing ./build/release/benchmark/benchmark_runner. The details of benchmarks are in our Benchmark Guide.
Please also refer to our Build Guide and Contribution Guide.
Support
See the Support Options page and the dedicated endoflife.date page.