Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
16.08.2018, 10:46
|
|||
---|---|---|---|
|
|||
Помогите оптимизировать запрос. |
|||
#18+
Как ускорить запрос SELECT * FROM user_message_entity ume inner join message_entity me on me.id = ume.message_entity_id WHERE to_tsvector('russian', message) @@ to_tsquery('russian', 'привет') and user_entity_id = 2; Повторный запрос работает быстрее , так как полностью чтение идет из буфера. Стоит поменять user_entity_id и запрос растягивается на десятки секунд из-за чтения с диска. Как то можно все в буфер загнать или какой-то другой способ решения? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 10:55
|
|||
---|---|---|---|
|
|||
Помогите оптимизировать запрос. |
|||
#18+
Rum11, 1)поставить нормальные диски 25s на чтение 35000 буферов это очень грустно и 2)поставить достаточно памяти чтобы основная рабочая часть базы там помещалась я бы с 1 начинал. Вопрос не к базе а к используемому оборудованию. Поставьте Intel optane диск и будуту цифры в 10000 раз меньше (по времени с диском) :)). PS: я бы еще work_mem бы поднял чтобы не было Heap Blocks: exact=43145 lossy=28665 но фундаментально это вам вопрос не решит. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 11:20
|
|||
---|---|---|---|
Помогите оптимизировать запрос. |
|||
#18+
Rum11, попробовать кластеризовать по user_entity_id. периодически. ? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 11:29
|
|||
---|---|---|---|
|
|||
Помогите оптимизировать запрос. |
|||
#18+
qwwq, Данные растут очень быстро. Придется постоянно делать кластеризацию , если я правильно Вас понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 11:43
|
|||
---|---|---|---|
Помогите оптимизировать запрос. |
|||
#18+
Rum11, а есть ли полнотекстовый индекс по message и индекс по user_message_entity.message_entity_id ? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 11:47
|
|||
---|---|---|---|
|
|||
Помогите оптимизировать запрос. |
|||
#18+
Alexius, Есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 11:51
|
|||
---|---|---|---|
Помогите оптимизировать запрос. |
|||
#18+
Rum11, а что показывает такой запрос ? Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 12:02
|
|||
---|---|---|---|
|
|||
Помогите оптимизировать запрос. |
|||
#18+
Alexius, Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 12:19
|
|||
---|---|---|---|
Помогите оптимизировать запрос. |
|||
#18+
Rum11, ок, значит исходный план оптимальный был для запроса с такими параметрами. к уже предложенным советам добавлю, что можно еще попробовать проверить bloat в таблицах и индексах и устранить его, если есть. возможно нужны не все поля из обоих таблиц и можно index only scan где-то сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.08.2018, 14:19
|
|||
---|---|---|---|
Помогите оптимизировать запрос. |
|||
#18+
Rum11qwwq, Данные растут очень быстро. Придется постоянно делать кластеризацию , если я правильно Вас понял. можно ещё партицировать по (диапазонам) user_entity_id. попаданий на странице будет много больше. такоже можно сначала отфильтровать не * а только ид (если я правильно понимаю, данные не апдейтятся почти) иос-ом (включить 2 поля в индекс) + фильтром по полнотексту, а только потом подтянуть поля (если полнотекст рубит сильно то выиграть может получиться) первой таблички по цтидам. и вообще уйти на мускул с его иот--кластерами (чисто теоретицки -- ибо не был, не привлекался) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=53&tablet=1&tid=1995626]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 149ms |
0 / 0 |