Skip to content

Revert making some of the queries runnable. #3644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 10, 2025
Merged

Revert making some of the queries runnable. #3644

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 5 additions & 10 deletions docs/managing-data/core-concepts/primary-indexes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ Each [data part](/parts) in the table has its own primary index. We can inspect

The following query lists the number of entries in the primary index for each data part of our example table:

```sql runnable=true
```sql
SELECT
part_name,
max(mark_number) as entries
Expand All @@ -82,7 +82,6 @@ GROUP BY part_name;


```txt
Static result for the query above from April 2025
┌─part_name─┬─entries─┐
1. │ all_2_2_0 │ 914 │
2. │ all_1_1_0 │ 1343 │
Expand All @@ -92,7 +91,7 @@ Static result for the query above from April 2025

This query shows the first 10 entries from the primary index of one of the current data parts. Note that these parts are continuously [merged](/merges) in the background into larger parts:

```sql runnable=true
```sql
SELECT
mark_number + 1 as entry,
town,
Expand All @@ -105,7 +104,6 @@ LIMIT 10;


```txt
Static result for the query above from April 2025
┌─entry─┬─town───────────┬─street───────────┐
1. │ 1 │ ABBOTS LANGLEY │ ABBEY DRIVE │
2. │ 2 │ ABERDARE │ RICHARDS TERRACE │
Expand All @@ -121,7 +119,7 @@ Static result for the query above from April 2025
```

Lastly, we use the [EXPLAIN](/sql-reference/statements/explain) clause to see how the primary indexes of all data parts are used to skip granules that can’t possibly contain rows matching the example query’s predicates. These granules are excluded from loading and processing:
```sql runnable=true
```sql
EXPLAIN indexes = 1
SELECT
max(price)
Expand All @@ -133,7 +131,6 @@ WHERE


```txt
Static result for the query above from April 2025
┌─explain────────────────────────────────────────────────────────────────────────────────────────────────────┐
1. │ Expression ((Project names + Projection)) │
2. │ Aggregating │
Expand All @@ -155,15 +152,14 @@ Static result for the query above from April 2025
Note how row 13 of the EXPLAIN output above shows that only 3 out of 3,609 granules across all data parts were selected by the primary index analysis for processing. The remaining granules were skipped entirely.

We can also observe that most of the data was skipped by simply running the query:
```sql runnable=true
```sql
SELECT max(price)
FROM uk.uk_price_paid_simple
WHERE (town = 'LONDON') AND (street = 'OXFORD STREET');
```


```txt
Static result for the query above from April 2025
┌─max(price)─┐
1. │ 263100000 │ -- 263.10 million
└────────────┘
Expand All @@ -173,12 +169,11 @@ Peak memory usage: 13.00 MiB.
```

As shown above, only around 25,000 rows were processed out of approximately 30 million rows in the example table:
```sql runnable=true
```sql
SELECT count() FROM uk.uk_price_paid_simple;
```

```txt
Static result for the query above from April 2025
┌──count()─┐
1. │ 29556244 │ -- 29.56 million
└──────────┘
Expand Down