added taskss greenplum optimization explain
This commit is contained in:
@@ -0,0 +1,53 @@
|
|||||||
|
## Задача 1:
|
||||||
|
|
||||||
|
EXPLAIN ANALYZE
|
||||||
|
SELECT user_id, COUNT(*)
|
||||||
|
FROM orders
|
||||||
|
GROUP BY user_id;
|
||||||
|
|
||||||
|
📌 `orders` распределена по `order_id`.
|
||||||
|
|
||||||
|
Что происходит:
|
||||||
|
|
||||||
|
```
|
||||||
|
Segment:
|
||||||
|
Seq Scan on orders
|
||||||
|
▼
|
||||||
|
Redistribute Motion (по user_id)
|
||||||
|
▼
|
||||||
|
HashAggregate (GROUP BY user_id)
|
||||||
|
```
|
||||||
|
|
||||||
|
💣 **Проблема:** Motion перед агрегированием — значит данные идут по сети между сегментами.
|
||||||
|
|
||||||
|
### Задание:
|
||||||
|
|
||||||
|
1. Что будет, если `orders DISTRIBUTED BY user_id`?
|
||||||
|
В таком случае таблица orders будет распределена по user_id между сегментами, соответственно счет будет внутри сегментов и не будет motion между сегментами.
|
||||||
|
2. Как меняется `EXPLAIN ANALYZE`
|
||||||
|
Не будет Redistribute Motion (по user_id)
|
||||||
|
|
||||||
|
## Задача 2:
|
||||||
|
|
||||||
|
SELECT user_id, COUNT(*)
|
||||||
|
FROM orders
|
||||||
|
GROUP BY user_id;
|
||||||
|
|
||||||
|
📌 `orders` содержит 10 млн заказов, и 90% из них у `user_id = 1`.
|
||||||
|
|
||||||
|
Что происходит:
|
||||||
|
|
||||||
|
```
|
||||||
|
Segment 1: user_id = 1 → 9 млн строк
|
||||||
|
Segment 2: остальные user_id → 1 млн строк
|
||||||
|
Segment 3–N: почти пусто
|
||||||
|
|
||||||
|
❗ Segment 1 перегружен → весь запрос тормозит
|
||||||
|
```
|
||||||
|
|
||||||
|
### Задание:
|
||||||
|
|
||||||
|
1. Как это называется?
|
||||||
|
Это называется "перекос"
|
||||||
|
2. Как избежать?
|
||||||
|
Сделать составной ключ по двум аргументам, либо разбить сегменты рандомно.
|
||||||
Reference in New Issue
Block a user