Skip to content

docs(operations): add Performance & Query Optimization guide#459

Open
gkorland wants to merge 1 commit intomainfrom
docs/add-performance-guide
Open

docs(operations): add Performance & Query Optimization guide#459
gkorland wants to merge 1 commit intomainfrom
docs/add-performance-guide

Conversation

@gkorland
Copy link
Copy Markdown
Contributor

@gkorland gkorland commented May 2, 2026

Summary

Create a comprehensive Performance & Query Optimization guide that teaches users how to diagnose and improve query performance.

Changes

  • New page: operations/performance.md covering:
    • Understanding query execution stages (parsing → planning → execution)
    • Using GRAPH.EXPLAIN to inspect plans (what Index Scan vs Node By Label Scan means)
    • Using GRAPH.PROFILE to measure per-operation metrics
    • Index selection guide (range, full-text, vector) with best practices
    • Parameterized queries for security and plan cache reuse
    • CACHE_SIZE tuning guidance
    • Query optimization patterns (LIMIT, early WHERE, RO_QUERY, bounded paths, WITH)
    • Monitoring with GRAPH.SLOWLOG
    • Quick reference checklist
  • operations/index.md: Added Performance guide link (section 13)

Testing

  • All internal links verified (/commands/graph.explain, /commands/graph.profile, etc.)
  • Front matter follows Operations page conventions

Memory / Performance Impact

N/A — documentation only

Related Issues

Addresses audit item P2.8 (Audit-Report.md)

Create operations/performance.md covering:
- Understanding query execution stages
- Using GRAPH.EXPLAIN to inspect execution plans
- Using GRAPH.PROFILE to measure per-operation metrics
- Index selection (range, full-text, vector) with best practices
- Parameterized queries for security and cache performance
- CACHE_SIZE tuning guidance
- Query optimization patterns (LIMIT, early filtering, RO_QUERY,
  bounded variable-length paths, WITH staging)
- Monitoring with GRAPH.SLOWLOG
- Quick reference checklist

Also adds the Performance guide to the Operations index page.

Addresses audit item P2.8.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 2, 2026

Warning

Rate limit exceeded

@gkorland has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 50 minutes and 53 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3c44bba3-9a57-4c56-86ea-b085f04179db

📥 Commits

Reviewing files that changed from the base of the PR and between f8fb86a and 13c4e30.

📒 Files selected for processing (2)
  • operations/index.md
  • operations/performance.md
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch docs/add-performance-guide

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
Review rate limit: 0/1 reviews remaining, refill in 50 minutes and 53 seconds.

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new Operations guide focused on diagnosing and improving FalkorDB query performance, and links it from the Operations index to make it discoverable within the production/deployment docs section.

Changes:

  • Added operations/performance.md covering EXPLAIN/PROFILE interpretation, index selection, parameterization, cache tuning, and monitoring/optimization patterns.
  • Updated operations/index.md to include the new Performance & Query Optimization page.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File Description
operations/performance.md New performance/optimization guide with examples and tuning guidance.
operations/index.md Adds a navigational entry pointing to the new guide.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread operations/performance.md
Best for similarity search on embedding vectors.

```cypher
CALL db.idx.vector.createNodeIndex('Document', 'embedding', 768, 'cosine')
Comment thread operations/performance.md
Comment on lines +135 to +148
Always use parameterized queries instead of string interpolation. This improves both **security** (prevents injection) and **performance** (enables query cache reuse).

**❌ Bad — string interpolation (new plan compiled every time):**

```python
name = "Alice"
graph.query(f"MATCH (p:Person {{name: '{name}'}}) RETURN p")
```

**✅ Good — parameterized (plan is cached and reused):**

```python
graph.query("MATCH (p:Person {name: $name}) RETURN p", params={"name": "Alice"})
```
Comment thread operations/performance.md
```
1) "Results"
2) " Project"
3) " Conditional Traverse | (p)->(friend:Person)"
Comment thread operations/performance.md

**Tuning guidance:**
- Increase `CACHE_SIZE` if your application uses many distinct query patterns
- Monitor cache effectiveness using `GRAPH.SLOWLOG` — if the same queries appear repeatedly, the cache may be too small
Comment thread operations/performance.md

### Use read-only queries when possible

Use `GRAPH.RO_QUERY` instead of `GRAPH.QUERY` for read-only operations. Read-only queries can be distributed to replicas, reducing load on the primary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants