m

db/sql/postgres/ext/backup/pgbackrest.txt

@@ -0,0 +1,2 @@
+https://pgbackrest.org/
+https://github.com/pgbackrest/pgbackrest

db/sql/postgres/feature/performance/explain/analyze.txt

@@ -1 +1,60 @@
 https://www.postgresql.org/docs/current/sql-analyze.html
+
+https://public.dalibo.com/exports/conferences/_archives/_2012/201211_explain/understanding_explain.pdf
+
+*************************************************************
+1. Обычный EXPLAIN ANALYZE показывает время выполнения, но не всегда объясняет, почему оптимизатор выбрал тот или иной путь. Попробуем расшифровать скрытые подсказки:  
+
+EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM orders WHERE user_id = 100 AND status = 'processed';
+
+Ключевые параметры:  
+BUFFERS - об этом параметре мы уже подробно писали (https://t.me/pg_guru/299), показывает, сколько данных было прочитано из кеша/диска;
+VERBOSE - раскрывает дополнительные детали, например, имена столбцов.  
+
+Если в выводе видим Buffers: shared hit=1534 read=217, это значит, что 1534 страницы были в кеше, а 217 пришлось читать с диска. Оптимизация может заключаться в увеличении work_mem или добавлении индекса, покрывающего запрос, а вовсе не в переписывании текста самого запроса.
+
+2. PostgreSQL выбирает алгоритм соединения таблиц на основе статистики. Но иногда ей можно помочь и принудительно указать тип JOIN (не всегда рекомендуется!)
+
+SET enable_nestloop = off;
+SET enable_hashjoin = on;
+SET enable_mergejoin = off;
+
+Когда что использовать:  
+Hash Join - хорош для больших несортированных таблиц;
+Merge Join - эффективен, если данные уже отсортированы (например, по индексу);
+Nested Loop - лучший выбор для маленьких таблиц или когда одна из них сильно фильтруется.  
+
+3. Вместо создания индекса на весь столбец можно оптимизировать место и использовать частичные или покрывающие индексы. Про такие виды индексов мы более подробно уже писали (https://t.me/pg_guru/666).
+
+Частичный индекс (только для "активных" заказов):
+
+CREATE INDEX idx_orders_active ON orders (user_id) 
+WHERE status = 'active';
+
+Покрывающий индекс:
+
+CREATE INDEX idx_orders_covering ON orders (user_id) INCLUDE (status);
+
+Если запрос запрашивает только user_id и status, PostgreSQL может выполнить Index Only Scan, вообще не обращаясь к таблице.  
+
+4. Работа с JSONB может быть медленной без правильных индексов.
+
+Создаём GIN-индекс для быстрого поиска по ключам:
+
+CREATE INDEX idx_gin_data ON users USING gin (profile_data);
+
+Мы можем создать индекс по конкретному JSON пути:
+
+CREATE INDEX idx_jsonb_path ON users 
+USING gin ((profile_data->'address'->>'city'));
+
+Теперь запросы вроде  
+
+SELECT * FROM users 
+WHERE profile_data @> '{"address": {"city": "Moscow"}}';
+
+будут работать гораздо быстрее.  
+
+На этом пока все! Будем развивать данную тему в будущих постах.
+
+Если у вас есть какие-то лайфхаки по оптимизации запросов в PostgreSQL, оставляйте их в комментариях. До связи!

nontech/philosophy/people/dugin/dugin.txt

@@ -5,6 +5,8 @@ DayTV - Expertise of Dugin
 https://www.youtube.com/playlist?list=PL2zbO1Ks2ovx0Enyg7bNzhCR8nZ0n7CmJ
 
 2025
+Infocelina - Kuznetsov - Dugin - Alyaska Results of 20:46
+    https://www.youtube.com/watch?v=IvGjkJlw7lM
 Sobolev - Dugin - Interview about Putin, RU World and Evolution of 1:03:00
     https://www.youtube.com/watch?v=i6VhvQVie3M
     ! 23:00 We Should say 3 No (capitalism, communism, ru-nationalism), return God

os/linux/cmdline/lazyjournal.txt

@@ -0,0 +1,2 @@
+https://pkg.go.dev/github.com/Lifailon/lazyjournal
+https://github.com/Lifailon/lazyjournal