CREATE INDEX session_id_idx ON golang (session_id);

Индекс не уникальный. Так? Сколько записей на одно значение session id в таблице (в среднем)

Таблица большая более 10тыс

Это маленькая . Меня интересует не таблица, а именно записей на одно значение session

Размер самой таблицы не важен

Это маленькая . Меня интересует не таблица, а именно записей на одно значение session

Одна это уникальный токен

А чего, скан по такому индексу лучше будет?

Да лучше идет.

Одна это уникальный токен

А почему у тебя ИНДЕКС НЕ уникальный?

Да лучше идет.

Да не рассказывай .

А чего, скан по такому индексу лучше будет?

При таком текстовом токене не уверен - при сравнении достаточно длинных текстовых сообщений (символов в 100) - hash индекс в нашем случае работал быстрее

При таком текстовом токене не уверен - при сравнении достаточно длинных текстовых сообщений (символов в 100) - hash индекс в нашем случае работал быстрее

На сколько быстрее ?

Сейчас найду историю переписки. Может планы даже до и после

есть запрос он выполняеться более 5тыс раз из за чего проседает бд можете подсказать как можно оптимизировать запрос или сделать решение которое ускорит вывод SELECT cdr.start_stamp as start_call, cdr.answer_stamp as takeoff, ivr_result.digits as press_key , ivr_result.time as press_key_time, cdr.end_stamp as hangup, cdr.billsec as call_duration, golang.uuid, cdr.hangup_cause, cdr.cc_record_filename, cdr.destination_number FROM golang LEFT JOIN result_obzvon ON golang.session_id = result_obzvon.session_id LEFT JOIN ivr_result ON golang.session_id=ivr_result.session_id LEFT JOIN cdr on golang.uuid = cdr.uuid WHERE golang.session_id = 'SWRZBwIsfh';

Вот этот запрос, в нём все связи 1:1 же у тебя ? Или всё же одна таблица 1:N ? Сколько записей запрос возвращает?

А hash индекс уже научился реплицироваться?

Сейчас найду историю переписки. Может планы даже до и после

Просто времена примерно одинаковые должны быть, что там что там. O(1+) и O(log N). Почти одно и то же. И ты советуешь при СКАНИРОВАНИИ Таблицы применять хэшиндекс, а он так наоборот не должен работать. Я ещё понимаю, где там в запросе сканирование, но просто странный совет.

есть запрос он выполняеться более 5тыс раз из за чего проседает бд можете подсказать как можно оптимизировать запрос или сделать решение которое ускорит вывод SELECT cdr.start_stamp as start_call, cdr.answer_stamp as takeoff, ivr_result.digits as press_key , ivr_result.time as press_key_time, cdr.end_stamp as hangup, cdr.billsec as call_duration, golang.uuid, cdr.hangup_cause, cdr.cc_record_filename, cdr.destination_number FROM golang LEFT JOIN result_obzvon ON golang.session_id = result_obzvon.session_id LEFT JOIN ivr_result ON golang.session_id=ivr_result.session_id LEFT JOIN cdr on golang.uuid = cdr.uuid WHERE golang.session_id = 'SWRZBwIsfh';

И чего тебя вообще там не устраивает (кроме 5 тыщ выполнений конечно) , если время выполнения 0.8 миллисекунд? Это шикарное время.

А hash индекс уже научился реплицироваться?

c 10-ки наконец да

всем привет, подскажите что может быть из неявного, причины почему индекс, практически в монопольном режиме, на таблице в 22млн записей не может создаться более 22 часов?

И чего тебя вообще там не устраивает (кроме 5 тыщ выполнений конечно) , если время выполнения 0.8 миллисекунд? Это шикарное время.

Там время 0.8 миллисекунды, а не микросекунды. но, да, всё дело в server-prepared

Ну, большая таблица же

индекс условный btree(id) where полеN is not null

Там время 0.8 миллисекунды, а не микросекунды. но, да, всё дело в server-prepared

Я описался. В голове было МИЛИ. И это всё ещё шикарное время.

да для нас вроде и не большая, есть и больше

на этой таблице правда параход индексов

да для нас вроде и не большая, есть и больше

Ну всю таблицу надо читать всё равно, и писать индекс. Другие индексы на данный влиять не будут.

какие параметры в настройках надо проверить, бд тестовая недавно развернутая

?

Размер Кэша, но он не очень сильно будет влиять.

кто ставил pgadmin4 на сервак?, подскажите как ему подключить сертификаты чтобы он по https работал

Просто времена примерно одинаковые должны быть, что там что там. O(1+) и O(log N). Почти одно и то же. И ты советуешь при СКАНИРОВАНИИ Таблицы применять хэшиндекс, а он так наоборот не должен работать. Я ещё понимаю, где там в запросе сканирование, но просто странный совет.

Конкретики я не нашел. В нашем случае hash был немного быстрее (в таблице около 400 тыс записей). Строка от 100 до 3000 символов. Тормоза в итоге решились переписыванием запроса.

какие параметры в настройках надо проверить, бд тестовая недавно развернутая

maintance_work_mem

autovacuum_work_mem -1 kB maintenance_work_mem 4194304 kB work_mem 131072 kB effective_cache_size 524288 8kB

А характеристики сервера?

Там ещё что-то про сортировку можно бы потюнить...

Но я не знаю что.

НАшёл

https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-WORK-MEM

pgtune + на время индексирования maintenance_work_mem побольше. Про остальное не подскажу. Надо смотреть утилизацию CPU при построении индекса - если у вас iowait - то явно не умещается индекс в maintenance_work_mem - надо поднимать

cat /proc/meminfo MemTotal: 16268356 kB MemFree: 433164 kB MemAvailable: 15436532 kB Buffers: 55936 kB Cached: 15120648 kB SwapCached: 36 kB Active: 8753892 kB Inactive: 6514656 kB Active(anon): 99952 kB Inactive(anon): 224032 kB Active(file): 8653940 kB Inactive(file): 6290624 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2097148 kB SwapFree: 2096596 kB Dirty: 364 kB Writeback: 0 kB AnonPages: 91968 kB Mapped: 238056 kB Shmem: 232020 kB Slab: 422144 kB SReclaimable: 397144 kB SUnreclaim: 25000 kB KernelStack: 2800 kB PageTables: 9420 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 18365504 kB Committed_AS: 2685880 kB VmallocTotal: 34359738367 kB VmallocUsed: 176916 kB VmallocChunk: 34359341052 kB HardwareCorrupted: 0 kB AnonHugePages: 40960 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 85952 kB DirectMap2M: 3059712 kB DirectMap1G: 15728640 kB

Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz stepping : 1 microcode : 0xb000014 cpu MHz : 2094.048 cache size : 40960 KB 4 ядра

autovacuum_work_mem -1 kB maintenance_work_mem 4194304 kB work_mem 131072 kB effective_cache_size 524288 8kB

в work mem гиг там кинь, а всё остальное в buffers (10-20% памяти оставь операционке)

Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz stepping : 1 microcode : 0xb000014 cpu MHz : 2094.048 cache size : 40960 KB 4 ядра

А памяти -то сколько ?

физ?

MemTotal: 16268356 kB

да

Это 16 гигоу?

ну гиг оставь операционке, гиг на work mem, 12 в кэш. Остальное на конфеты...

если накидываю и перечитываю конфиги, то текущее создание индекса прервется уже

?

Коллеги, подскажите, пожалуйста. У меня есть БД . К БД обращается сервер 2200 раз в сек и получает информацию. Порядка 99% информации не изменяется , хранится статично. Каким образом (какие технологии) можно закешировать редко изменяемую информацию БД, чтобы сервер обращался не в БД, а в кеш. Тем самым ускорить получении информации. Но при изменении данных в БД, должен обновляться кещ либо сервер должен брать измененную инфу из БД.

Коллеги, подскажите, пожалуйста. У меня есть БД . К БД обращается сервер 2200 раз в сек и получает информацию. Порядка 99% информации не изменяется , хранится статично. Каким образом (какие технологии) можно закешировать редко изменяемую информацию БД, чтобы сервер обращался не в БД, а в кеш. Тем самым ускорить получении информации. Но при изменении данных в БД, должен обновляться кещ либо сервер должен брать измененную инфу из БД.

СУБД итак кеширует данные за вас. Это не считая ещё дисковых кешей и кеша ОС.

если накидываю и перечитываю конфиги, то текущее создание индекса прервется уже

Так ты сервер должен перегрузить.

СУБД итак кеширует данные за вас. Это не считая ещё дисковых кешей и кеша ОС.

Тоесть если я буду делать 2200 селектов в секунду , каждый селект возращает строку со 100 полями, это для Postgres не проблема, верно?

ну гиг оставь операционке, гиг на work mem, 12 в кэш. Остальное на конфеты...

Из доки Для большинства методов индексов скорость создания индекса зависит от значения maintenance_work_mem. Чем больше это значение, тем меньше времени требуется для создания индекса (если только заданное значение не превышает объём действительно доступной памяти, что влечёт за собой использование подкачки).

Коллеги, подскажите, пожалуйста. У меня есть БД . К БД обращается сервер 2200 раз в сек и получает информацию. Порядка 99% информации не изменяется , хранится статично. Каким образом (какие технологии) можно закешировать редко изменяемую информацию БД, чтобы сервер обращался не в БД, а в кеш. Тем самым ускорить получении информации. Но при изменении данных в БД, должен обновляться кещ либо сервер должен брать измененную инфу из БД.

Ну не надо так. Не надо обращаться к БД 2200 раз в сек. Запоминай информацию вне БД. Как — вопрос не к нам, а к разработчикам твоего приложения.

Из доки Для большинства методов индексов скорость создания индекса зависит от значения maintenance_work_mem. Чем больше это значение, тем меньше времени требуется для создания индекса (если только заданное значение не превышает объём действительно доступной памяти, что влечёт за собой использование подкачки).

Ну, может быть. Я не админ, не знаю.

Ребята спасибо, пошел, тюнить) индекс лучше заново пересоздать?

наврятли он переживет переделку конфига

Тоесть если я буду делать 2200 селектов в секунду , каждый селект возращает строку со 100 полями, это для Postgres не проблема, верно?

Не проблема. Другой вопрос, зачем нужны такие запросы.

Не проблема. Другой вопрос, зачем нужны такие запросы.

В БД хранятся конфиг файлы. Клиенты запрашивают их у сервера.

В БД хранятся конфиг файлы. Клиенты запрашивают их у сервера.

Зачем так часто? Если это разные клиенты, то у них у всех одинаковые конфиги, выходит?

Риторический вброс: хранить конфиги в БД вообще моветон, лучше их хранить именно в файлах, хоть в JSON и раздавать как статику nginx-ом. Нереально снизит нагрузку. Но, видимо, это тот случай, когда "так исторически сложилось"?

сказали что на продуктиве 256гб оперативки так что норм сейчас на время создания до 12 поднимем maintenance_work_mem и будем ждать

ну гиг оставь операционке, гиг на work mem, 12 в кэш. Остальное на конфеты...

Гиг на work_mem - это как? work_mem - это память под сортировки КАЖДОЙ сессии. С таким раскладом 16 гиг кончатся быстро )))

Гиг на work_mem - это как? work_mem - это память под сортировки КАЖДОЙ сессии. С таким раскладом 16 гиг кончатся быстро )))

Это просто циферка для оптимизатора. Так-то кончится ещё быстрее.

Гиг на work_mem - это как? work_mem - это память под сортировки КАЖДОЙ сессии. С таким раскладом 16 гиг кончатся быстро )))

Не знал. Не я имел в виду целиком всё. Все сессии

Зачем так часто? Если это разные клиенты, то у них у всех одинаковые конфиги, выходит?

Конфиги частично разные. Частые запросы нужны для оперативного управления. Возникла внештатная ситуация - изменил конфиги в БД и через минуту все клиенты поднялись. Мы видим это как-то так

Гиг на work_mem - это как? work_mem - это память под сортировки КАЖДОЙ сессии. С таким раскладом 16 гиг кончатся быстро )))

Да это всё равно грубый набросок, ему всё равно надо будет более детально думать

ERROR: S client not available

Я бы начал с 25% RAM для буферного кеша, а не с 75%

SELECT DISTINCT orders.order_id, CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate FROM orders WHERE orders.service_id NOT IN (7100,4100,7200,1000,8100) ORDER BY jobdate DESC NULLS LAST, order_id DESC LIMIT 100 OFFSET 0 как можно улучшить: CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate так как на нее уходит основное время запроса

Конфиги частично разные. Частые запросы нужны для оперативного управления. Возникла внештатная ситуация - изменил конфиги в БД и через минуту все клиенты поднялись. Мы видим это как-то так

Можно отправлять бекендом эвент обновления конфига клиентам, в случае изменений, и тогда ничего не нужно опрашивать 2200 раз в секунду.

SELECT DISTINCT orders.order_id, CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate FROM orders WHERE orders.service_id NOT IN (7100,4100,7200,1000,8100) ORDER BY jobdate DESC NULLS LAST, order_id DESC LIMIT 100 OFFSET 0 как можно улучшить: CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate так как на нее уходит основное время запроса

А как ты понял, что на неё уходит основное время ?

SELECT DISTINCT orders.order_id, CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate FROM orders WHERE orders.service_id NOT IN (7100,4100,7200,1000,8100) ORDER BY jobdate DESC NULLS LAST, order_id DESC LIMIT 100 OFFSET 0 как можно улучшить: CASE WHEN (orders.tip_id IS NOT NULL AND orders.customer_id = the_company()) THEN COALESCE(orders.tip_date, orders.current_req_for) ELSE COALESCE(orders.current_jobdate, orders.current_req_for) END as jobdate так как на нее уходит основное время запроса

Покажите план.

Покажите план.

https://explain.depesz.com/s/Nqxz

У вас секскан и сортировка тяжелая без индекса. Case тут не при чём

Можно отправлять бекендом эвент обновления конфига клиентам, в случае изменений, и тогда ничего не нужно опрашивать 2200 раз в секунду.

Такой возможности нет.

ипопея с долгим индексом: накинули память, то создание отменил, точнее кинул отмену, но запрос все равно висит в активе это видимо тоже надолго?

У вас секскан и сортировка тяжелая без индекса. Case тут не при чём

спасибо, но на service_id есть индекс я думаю планировщик выбирает сам секскан

пробовал pg_cancel_backend и pg_terminate_backend

ипопея с долгим индексом: накинули память, то создание отменил, точнее кинул отмену, но запрос все равно висит в активе это видимо тоже надолго?

Посмотрите на блокировки. А вы конкурентно индекс создавали или нет?

нет, поскольку накат ченжей подразумевает условную монополию, то индексы без конкурентли

локов нет)

Пруф что без локов

нет, поскольку накат ченжей подразумевает условную монополию, то индексы без конкурентли

А в чём противоречие конкурентного создания индекса и монопольного наката изменений?

спасибо, но на service_id есть индекс я думаю планировщик выбирает сам секскан

А если без сортировки и без лимита, индекс используется?

А если без сортировки и без лимита, индекс используется?

нет, почему так может быть?

Потому чтовозможно, у вашего условия низкая селективность для использования индекса.

Количество записей, которые надо выбрать значительно больше тех, которые отбрасываются по вашему условию

Количество записей, которые надо выбрать значительно больше тех, которые отбрасываются по вашему условию

да так и есть

А в чём противоречие конкурентного создания индекса и монопольного наката изменений?

монопольное условное, просто во время наката подразумевается что никто не работает с прикладом

соответственно эта таблица не используется, нет блокировок

можно индекс делать без конкрурентли

мы просто на тесте тестируем переход на новую версию

приклада

Т.е. вы отключаете пользователей, обрубаете сессии в момент наката?

да это достаточно редкое явление) примерно раз в месяц

обновление релиза

но если индекс будет долго создаваться, мы не успеем в рамки отведенного времени

там тонна ченжсетов

Это на тесте/стейдже он у вас долго создаётся?