diff --git a/dmedvedev/4.3.greenplun_optimization_explain.sql b/dmedvedev/4.3.greenplun_optimization_explain.sql
new file mode 100644
index 0000000..a81c501
--- /dev/null
+++ b/dmedvedev/4.3.greenplun_optimization_explain.sql
@@ -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. Как избежать?
+        Сделать составной ключ по двум аргументам, либо разбить сегменты рандомно.
\ No newline at end of file