Правильно, лучше REGEXP

Вообще это всё (в том числе и моё решение) выглядит не сильно надёжно. Ведь нули вообще могут рано или поздно пропасть - и как тогда обрезать?

ну так исходное условие же получить все цифры после нулей ?
или может последние 4 цифры ?
@nurbek_khaydarov
поясните )

Привет. ОРМка генерит дважды дублирующийся where clause через AND - замедлит ли это запрос?

explain ... ваш запрос все покажет

what ?
какие ваши доказательства ?
запросик в студию

Сам запрос скинуть не могу, увы, а в общих чертах вот что происходит:

SELECT A.*
FROM A JOIN B ON B.fk = A.pk
WHERE B.col1 = val1 AND B.col2 = val2 AND B.col1 = val1
GROUP BY A.pk ORDER BY A.seqnum DESC
LIMIT 500

Если не секрет, это что за ORM генерит так? Запрос не замедлит, просто интересно

аа, думаю что это совсем не страшно и постгрес на этапе подготовки запроса проигнорирует данное условие
а вообще.. может дело не в orm, а в конкретно написанном в ней запросе ?

Алхимия. Но тут дело в том, что наш билдер квери дважды этот clause записал - интересуюсь, так ли это критично, поскольку починить немного трудно

Так возьмите 2 варианта запроса и сравните вывод EXPLAIN для них. EXPLAIN ANALYZE SELECT  ...

Да, дело не в ОРМ

В EXPLAIN ничего не меняется, разве что execution time без второго clause в среднем самую малость меньше. Решил переспросить, нет ли подводных камней.

Благодарю

"execution time без второго clause в среднем самую малость меньше" - я думаю, это не связано с наличием/отсутствием второго условия. Время выполнения запроса всегда слегка различается - это нормально

Всем привет, может кто подсказать по проблеме?

Суть такая:

8 CPU
20 GB RAM

Version: 11.3
shared_buffers,4GB
wal_buffers,16MB
wal_sender_timeout,1min
work_mem,24MB
min_wal_size,1GB
max_wal_size,16GB
effective_cache_size,7GB

Wal sender выжирает весь доступный swap, на данный момент он полностью забит. Свободной памяти 100 метров. 5 слотов логической репликации поделили между собой весь swap.
В этих слотах идет постоянное обновление\удаление\запись данных. База сама весит 350 гигов.
Как-то возможно заставить wal sender перестать выжирать его?
Накинуть еще оперативы или может что-то другое поможет?

дополните сообщение версией постгреса

Добавил

> Wal sender выжирает весь доступный swap

то есть всё-так пять валсендеров, верно? (ведь слотов 5)

> 5 слотов логической репликации поделили между собой весь swap

а по наблюдению через vmstat наблюдается ли активное чтение или запись из свопа? (смотреть на поля swap si/so)

статистику валесендеров и слотов репликации смотрели? наблюдается ли там лаг репликации и лаг вычитки слотов? (pg_stat_replication и pg_replication_slots)

Слотов всего 7, 2 из них в swap не лезут, притом, что в одном из слотов как раз идет активное удаление данных и вставка.
Лагов в слотах тоже как таковой нет.
Через vmstat использования свопа тоже нет, он просто забит полностью, крайне редко (раз в час-два) бывает мизерный swap out на 0.08 B/s и все

а еще по обычным соединениям подскажите, сколько всего обычно установлено и сколько активных в пике бывает