Доброго времени суток! Подскажите пожалуйста, если кто знает, по pg_trgm Впервые

вижу работу запросов с этим расширением. Проблема в том, что при выполнении запросов создается 100% нагрузка на ядро ЦПУ. Могу показать пример структуры запроса. Или возможно это особенность работы с триграммами? Размер таблицы ~400к строк

Хмм... создаётся и отлично, там же CPU купили не для того, чтобы он спал? ;) Т.е. проблемы есть какие-то от этого?

С учётом такого небольшого размера таблицы, никаких ядер не хватит

Просто пытаюсь понять. Это особенность работы или запрос неправильно составлен?

Хмм? Я напишу по-другому — если какая-то СУБД не нагружает CPU на 100%, когда у неё есть единственный запрос для выполнения (и нет ожиданий диска, RAM и т.п.) — это её дефект. Вы хотите, чтобы в PostgreSQL был дефект? ;) Или в чём реальная проблема?

У меня получается картина, что на 34 базы под рабочей нагрузкой, эта база с запросами pg_trgm составляет 60% загрузка цпу всего сервера. Я и пытаюсь понять нормальная ли эта картина при работе с этим расширением или где то что то идёт не так.

Так, может, другие запросы (к другим базам) в основном "простые" (типичные для OLTP)? Если так — у них-то как раз накладных расходов много. А триграммный индекс, скорее всего, создан для чего-то "тяжёлого" (иначе бы его там не было, верно?), вот такие запросы и выбиваются из общего ряда.

Да, через pg_trgm ищутся и сопоставляются различные строки произвольной длины (до 50 символов) , плюс транслитерация этих строк. Благодарю за ответы! Видимо это просто так работает и либо стоит смириться, либо не использовать реляционки для этих целей.

> Видимо это просто так работает и либо стоит смириться С чем "смириться", о чём Вы?! > либо не использовать реляционки для этих целей. Извните, но я один не понимаю, как Вам удалось сделать этот "вывод"?! ;(

Смириться, что запрос такого характера будет давить цпу на полную.

И Вы считаете это недостатком потому, что... что?

Возможно я ошибаюсь конечно. Могу показать план запроса. Но лично я в нем не вижу ничего криминального.

Вы, мне кажется, если и ошибаетесь, то фундаментально (путаете чёрное с белым). Вы мне можете объяснить, почему Вы считаете... см. выше?

Боюсь исчерпать железные ресурсы на, сравнительно, небольших размерах базы.

Если что, я не претендую на какого либо гуру postgresql. Просто попался случай и пытаюсь с ним разобраться.

Да, Вы путаете чёрное с белым. ;) Ресурсы же не "исчёрпываются", они нужны для того, чтобы их использовать. Если у Вас [слишком] много запросов — что-то "подвинется", как всегда. Но то, что "тяжёлые" запросы забирают 100% какого-то из нужных им ресурсов — это норма (или же к этому стоит стремиться). Хуже, если не забирают (т.е. СУБД не способна использовать всё "железо", которое ей дают).

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

Да это же "общие знания о природе", как говорится. Мне смутно вспоминается, что про mainframes в своё время говорили что-то вроде "если у вас нагрузка всех CPU постоянно ниже 90%, значит вы впустую тратите деньги".

Мне уже начинает казаться, что Вы не читаете то, что я Вам пишу. :( У Вас настоящая проблема есть какая-то? Что-то тормозит и т.п.?

Я понял вашу точку зрения. Больше утилизация = лучше. Но соседние базы будут не очень рады в определенный момент. Но тогда решение одно - отселить прожору и дать ему ресурсов столько, чтобы хватило, но не простаивало

Он "подвинется", если "соседним базам" это будет нужно. И это же не "магия", а обычная вытесняющая многозадачность OS...