Сделал первый в своей жизни триггер. Спасибо, дядя Олег, за то, что у тебя индексы от функции не прошли.

Рекурсивный запрос для выбора трека для обновления с какого-то хуя пошел по пизде и стал выполняться две минуты. Благо в ночь с субботу на воскресенье. И чтобы меня запутать — еще и почта россии повалилась. А я на этот запрос еще логики навесил хитрой, так что пиздец полный, не разобрать уже, что и почему. Заменил на SKIP LOCKED, про который я в #6RCQXB прочитал. Вроде работает.

http://pgconf.org.np/ обосрался

Ура, блять: зависшие транзакции в бекендах, подключения к которым давно сдохли. Куда этот постгрес ебнуть?

https://blog.2ndquadrant.com/what-is-select-skip-locked-for-in-postgresql-9-5/ ох ебать меня в рот, SKIP LOCKED надо попробовать где-нибудь, у меня сейчас везде на адвизори локах

test=> CREATE TABLE t AS SELECT * FROM (SELECT generate_series(1,10000) AS a) q1, (SELECT generate_series(1,2) AS b) q2; SELECT 20000 test=> CREATE INDEX i ON t (a); CREATE INDEX test=> EXPLAIN SELECT * FROM t ORDER BY a LIMIT 5; Limit (cost=0.29..0.44 rows=5 width=8) -> Index Scan using i on t (cost=0.29..620.29 rows=20000 width=8) test=> EXPLAIN SELECT * FROM t ORDER BY a, b LIMIT 5; Limit (cost=621.19..621.21 rows=5 width=8) -> Sort (cost=621.19..671.19 rows=20000 width=8) Sort Key: a, b -> Seq Scan on t (cost=0.00..289.00 rows=20000 width=8) Какого хуя?

Совет дня: вместо timestamp = NULL используйте timestamp = &#39;0001-01-01&#39; Потому что условие timestamp IS NULL OR timestamp < now() - interval &#39;1 hour&#39; ни хуя не умеет использовать индекс по timestamp. Хоть в индексе NULLS FIRST, хоть NULLS LAST, это только на ORDER BY влияет.

REFRESH MATERIALIZED VIEW CONCURRENTLY занимался хуйней 15 минут и обосрался ошибкой своих кишок про какой-то там FULL JOIN. Никогда не пользуйтесь матвьюхами в постгресе, это говно.

На работе скучно. Развернул в авитник дамп OSM по рашеньке. Сделал для avito.link/map фильтр на леса, реки и очевидные промзоны при помощи LEFT JOIN polygon ON ST_intersects(polygon.way, ...) WHERE polygon.way IS NULL. Условие на невхождение каждого ебаного объявления в 3 млн. полигонов из черного списка работает незаметно быстро, спасибо Бартунову за детство счастливое наше. Шума в промзонах и на окраинах стало немного меньше. Такой день.

wal_keep_segments = 512 # in logfile segments, 16MB each; 0 disables реплика все равно НЕ УСПЕЛА

таблица в 30 000 000 строк на обоссаной блиннице тупой поиск WHERE string LIKE &#39;...%&#39; с последующей сортировкой ORDER BY created_at DESC для которого был сознательно создан тупой btree-индекс, зато с varchar_pattern_ops изредка, при некоторых запросах (например, на строке "zzz", которая из букв в конце алфавита) планировщик решает, что нехуй искать по индексу для string, а нужно спускаться по created_at DESC — в таблице в 30 млн строк по очевидным причинам запрос выолняется довольно долго и какого-то хуя не прибивается хатэтэтэ-сервером после таймаута разумеется, я тут не хуй собачий, и все долгие запросы логируются только нихуя это не дало, потому что явление довольно редкое и за остальным шумом не видно но так как выполняется такая срань несколько часов, то после прибития к хуям индекса по created_at DESC обнаружилось, что на эту ебанину приходилось 80% нагрузки на сервер о сколько нам открытий чюдных, блять

Я не знаю, каким, блять, образом, но REFRESH заблочил мне к хуям всю базу. Никогда не пользуйтесь матвьюхами в постгресе, это костыли.

поцтгрес немного поработал и решил, что искать по специальному индексу для поиска ебаной строки больше не рационально а то там же еще ORDER BY created_at DESC в конце, сортировать потом заебешься, ну его нахуй лучше по индексу на created_at по таблице 25 000 000 элементов вниз спускаться и фильтровать строки одна за другой и разумеется, в данном конкретном результат поиска — 1 (одна) строка

Коротко о pg_strom: за те же деньги можно купить ведро SSD и полведра памяти.

Завел pg_strom на Nvidia Tesla K40c. Придумайте смешных агрегаций, пока я качаю 70 гигабайт базы.

Умеет понимать, что хотят от WHERE NOT EXISTS (SELECT 1 FROM ...) и перепланировать по своему вкусу. Охуеть можно.

Никогда не используйте CREATE INDEX CONCURRENTLY. Оно вам молча насоздает паленых индексов, которые молча ни хуя не работают.

til CREATE INDEX CONCURRENTLY о сколько нам открытий чюдных