|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#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:46 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#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, 10:55 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Rum11, попробовать кластеризовать по user_entity_id. периодически. ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 11:20 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
qwwq, Данные растут очень быстро. Придется постоянно делать кластеризацию , если я правильно Вас понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 11:29 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Rum11, а есть ли полнотекстовый индекс по message и индекс по user_message_entity.message_entity_id ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 11:43 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Alexius, Есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 11:47 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Rum11, а что показывает такой запрос ? Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 11:51 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#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:02 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Rum11, ок, значит исходный план оптимальный был для запроса с такими параметрами. к уже предложенным советам добавлю, что можно еще попробовать проверить bloat в таблицах и индексах и устранить его, если есть. возможно нужны не все поля из обоих таблиц и можно index only scan где-то сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 12:19 |
|
Помогите оптимизировать запрос.
|
|||
---|---|---|---|
#18+
Rum11qwwq, Данные растут очень быстро. Придется постоянно делать кластеризацию , если я правильно Вас понял. можно ещё партицировать по (диапазонам) user_entity_id. попаданий на странице будет много больше. такоже можно сначала отфильтровать не * а только ид (если я правильно понимаю, данные не апдейтятся почти) иос-ом (включить 2 поля в индекс) + фильтром по полнотексту, а только потом подтянуть поля (если полнотекст рубит сильно то выиграть может получиться) первой таблички по цтидам. и вообще уйти на мускул с его иот--кластерами (чисто теоретицки -- ибо не был, не привлекался) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2018, 14:19 |
|
|
start [/forum/topic.php?fid=53&msg=39688669&tid=1995626]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 146ms |
0 / 0 |