You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge origin/master into yarik/case-insensitive-identifiers
Resolved conflicts:
- `IdentifierNode.cpp`: adapted `setQuoteStyles` to use `make_intrusive` instead of `std::make_shared`
- `QueryAnalyzer.cpp`: combined PR's `is_part_double_quoted` tracking with master's `allow_to_resolve_niladic_functions` parameter; added both new extern settings
- `Settings.h`: added both `CaseInsensitiveNames` and `DeduplicateInsertMode` setting types
- `ExpressionElementParsers.cpp`: adapted `setQuoteStyle`/`setQuoteStyles` calls to use `make_intrusive`
When working with a branch, do not use rebase or amend - add new commits instead.
2
2
3
+
Do not commit to the master branch. Create a new branch for every task.
4
+
3
5
When writing text such as documentation, comments, or commit messages, wrap literal names from ClickHouse SQL language, classes and functions, or literal excerpts from log messages inside inline code blocks, such as: `MergeTree`.
4
6
5
7
When writing text such as documentation, comments, or commit messages, write names of functions and methods as `f` instead of `f()` - we prefer it for mathematical purity when it refers a function itself rather than its application.
6
8
7
9
When mentioning logical errors, say "exception" instead of "crash", because they don't crash the server in the release build.
8
10
9
-
Links to ClickHouse CI, such as `https://s3.amazonaws.com/clickhouse-test-reports/json.html?...` should be interpreted with a headless browser, e.g., Playwright, because they contain JavaScript. Use the tool at `.claude/tools/fetch_ci_report.js`:
11
+
Links to ClickHouse CI should be analyzed using the tool at `.claude/tools/fetch_ci_report.js`, which directly fetches the underlying JSON data without requiring a browser. It accepts GitHub PR URLs (fetches all CI reports) or direct S3/CI HTML URLs.
# --report <number> For PR URLs: fetch only one specific report
36
+
# --download-logs Download logs.tar.gz to /tmp/ci_logs.tar.gz
37
+
# --credentials <user,password> HTTP Basic Auth for private repositories
28
38
```
29
39
30
40
After downloading logs, extract specific test logs:
@@ -33,6 +43,122 @@ tar -xzf /tmp/ci_logs.tar.gz ci/tmp/pytest_parallel.jsonl
33
43
grep "test_name" ci/tmp/pytest_parallel.jsonl | python3 -c "import sys,json; [print(json.loads(l).get('longrepr','')) for l in sys.stdin if 'failed' in l]"
34
44
```
35
45
46
+
To analyze CI performance comparison results (slower/faster queries, unstable queries), use the tool at `.claude/tools/fetch_perf_report.py`. It fetches the machine-readable `all-query-metrics.tsv` from S3 for each performance shard, filters to `client_time`, and classifies queries as changed or unstable using the same thresholds as `compare.sh`.
47
+
48
+
```bash
49
+
# Show performance changes for a PR (default: changed + unstable queries only)
Key options: `--arch <amd|arm|all>` to filter architecture, `--metric <name>` to change metric (default `client_time`), `--shard <n>` for a specific shard, `--test <name>` / `--query <text>` for substring filtering, `--sort <diff|times|threshold|test>` for ordering, `--summary` for shard-level overview only, `--json` / `--tsv` for machine-readable output.
75
+
76
+
To compile and run C++ code snippets against the ClickHouse codebase without modifying any source files, use the tool at `.claude/tools/cppexpr.sh`. This is a wrapper around `utils/c++expr` that auto-detects build directories and handles working directory setup. When asked about the size, layout, or alignment of ClickHouse data structures, or asked to compare performance of code snippets, use this tool to get a definitive answer instead of guessing.
Key options: `-i HEADER` to include headers, `-g 'CODE'` for global-scope code, `-b STEPS` for benchmarking, `-l LIB` to link extra libraries, `--plain` for standalone compilation without ClickHouse. The `OUT(expr)` macro prints `expr -> value`.
96
+
97
+
When asked to analyze assembly, inspect generated code, find register spills, check branch density, compare codegen between builds, or investigate optimization opportunities in compiled functions, use the tool at `.claude/tools/analyze-assembly.py`. It disassembles functions from a compiled binary, builds a CFG, computes metrics (spill/branch/call density), and reports findings. Use it instead of manually running `llvm-objdump` or `llvm-nm`.
Key options: `--search` for regex matching, `--fuzzy` for substring matching, `--select N` to pick from ambiguous results, `--all` to analyze all matches, `--context N` to show surrounding symbols, `--max-instructions N` to control output size, `--mca --mcpu=<model>` for llvm-mca throughput analysis, `--perf-map <file>` for runtime-weighted scoring, `--before`/`--after` for diff mode. Hex addresses (e.g. `0x0dc7c780`) are resolved to the enclosing symbol automatically — useful when symbol names are too long for regex matching. The tool caches symbol tables by build-id for fast repeated queries.
132
+
36
133
You can build multiple versions of ClickHouse inside `build_*` directories, such as `build`, `build_debug`, `build_asan`, etc.
37
134
38
135
You can run integration tests as in `tests/integration/README.md` using: `python -m ci.praktika run "integration" --test <selectors>` invoked from the repository root.
136
+
137
+
When writing tests, do not add "no-*" tags (like "no-parallel") unless strictly necessarily.
138
+
139
+
When writing tests in tests/queries, prefer adding a new test instead of extending existing ones.
140
+
141
+
When adding a new test, consult `./tests/queries/0_stateless/add-test` to determine the correct name prefix for the new test.
142
+
143
+
When writing C++ code, always use Allman-style braces (opening brace on a new line). This is enforced by the style check in CI.
144
+
145
+
Never use sleep in C++ code to fix race conditions - this is stupid and not acceptable!
146
+
147
+
When writing messages, say ASan, not ASAN, and similar (because there are two words: Address Sanitizer).
148
+
149
+
When checking the CI status, pay attention to the comment from robot with the links first. Look at the Praktika reports first. The logs of GitHub actions usually contain less info.
150
+
151
+
Do not use `-j` argument with ninja; do not use `nproc` - let it decide automatically.
152
+
153
+
When building ClickHouse (running ninja), always redirect output to the build log file in the build directory. Always use a subagent to analyze the log and return only a concise summary.
154
+
155
+
When running tests, always redirect output to a log file in the build directory (e.g. `<build_directory>/test_<test_name>.log`). Use unique file names per test so multiple tests can run in parallel. Always use a subagent to analyze each log and return only a concise summary.
156
+
157
+
If I provided a URL with the CI report, logs, or examples, include it in the commit message.
158
+
159
+
When creating or updating a pull request, use `.github/PULL_REQUEST_TEMPLATE.md` as the PR body template. The body should contain: a short description of the change and motivation, then the Changelog category (leave one from the list), then the Changelog entry, then the Documentation entry checkbox. Do not invent a custom "## Summary" or "## Test plan" structure — follow the template exactly. The "Bug Fix" category should be used only for real bug fixes, while for fixing CI reports you can use the "CI Fix or improvement" category. Include the URL to CI report I provided if any. If the PR is about a CI failure, search for the corresponding open issues and provide a link in the PR description.
160
+
161
+
ARM machines in CI are not slow. They are similar to x86 in performance.
162
+
163
+
Use `tmp` subdirectory in the current directory for temporary files (logs, downloads, scripts, etc.), do not use `/tmp`. Create the directory if needed.
0 commit comments