diff --git a/mnoskov/greenplum/practice_requests.txt b/mnoskov/greenplum/practice_requests.txt
new file mode 100644
index 0000000..4c4fbde
--- /dev/null
+++ b/mnoskov/greenplum/practice_requests.txt
@@ -0,0 +1,17 @@
+Задание 1:
+- Будут собираться все 10млн строк с разных сегментов, а тольок потом сработает LIMIT. Это очень дорого стоит, и медленно тк очень много данных в пустую соединятся в мастер.
+- Я думаю можно к текущему запросу добавить DENSE_RANK по total и написать условие where -тут имя dense_rank- <= 10.
+!!! В теории не сказано про работу order by - пришлось загуглить !!!
+
+Задание 2:
+- PARTITION BY по. region_id, а должен быть по order_id, чтобы работало без задержек, а при текущем варианте запроса будет происходить data motion как я понял, а это лишние вычисления.
+- Тогда надо распределять таблицу по region_id полагаю.
+
+Задание 3:
+- Ответ до подсказки: думаю все будет нормально, данные просто сгруппируются и вставятся, никаких зарежек быть не должно.
+- Ответ после подсказки: greenplum будет пересылать(data motion) user_id между сегментами, чтобы собрать их в группы, а только потом собирать в мастер и инсертить, инсерт уже поидее будет происходить хорошо, тк данные после data motion будут лежать нормально.
+- Orders надо дестрибьютить по user_id, тогда все четко и быстро будет - и group by, и join.
+
+Задание 4:
+- Я хочу увидеть Motion, Broadcast, Gather
+- Что означает Broadcast Motion, Redistribute Motion, Gather Motion? - в душе ни чаю, там вопрос с ответом сразу, взял оттуда: Broadcast Motion - разослать копии каждой строки на все сегменты; Redistribute Motion - перераспределить по новому ключу; Gather Motion - собрать на мастер.
\ No newline at end of file