|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
На входе: matrix_table.products формата: [{"cost": 674, "product_id": 34}, {"cost": 716, "product_id": 43}] Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
Запросы выполняется не очень быстро. У меня подозрения что можно сделать быстрее, но пока я не понял как. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 16:50 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., Код: sql 1. 2. 3. 4. 5. 6.
Ничего не забыл? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 17:20 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Фантастика. Процедура стала работать в несколько раз быстрее. Только join почему-то выполняется почти также долго (он для представления many-to-many отношений): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
С индексами gin этот большой запрос выполняется в несколько раз дольше. Вопрос: если использовать CREATE MATERIALIZED VIEW, то будет ли ускорение при регулярном вызове? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 17:55 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
При этом создание индексов добавляет к поиску 0,1 мсек, вместо ускорения, что весьма странно. Код: sql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 18:12 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Результат вызова хранимки индексов не предусматривает. Соответственно переджойнить setof пары хранимок кроме как прямым полным перебором не получится. Емнип, language sql хранимка из одного выражения может инлайнится в вызывающий запрос и переписаться оптимизатором. Ещё вам поможет простой view вместо вызова хранимки. Т.к. его оптимизатор тоже переписать сможет для использования некоторых индексов. Если догадается, какие индексы вам нужны. Или, что очевиднее, целиком переписать задачу, начиная с головы, а не с хвоста и думая, где можно отсеять максимум ненужных строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 18:28 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
С хранимыми процедурами стало быстрее на несколько секунд, чем версия из первого поста. Сейчас попробую без них, ожидаю что станет существенно быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 18:37 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Скорость получилось точно такая же как с хранимыми процедурами - 15 секунд ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 18:48 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Странно, вы начали обсуждение производительности запроса и не предъявили ни explain, ни explain (analyze, buffers) ни даже сам запрос. Я уж не говорю о DDL таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 20:47 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Melkij, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
1. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
2. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:35 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., В том же порядке. 1. ANALYZE, BUFFERS Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
2. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:38 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., ага, оптимизатор заинлайнил подзапросы и результат ухудшился. Ладно, бывает. Но вам реально надо вычитать всё или всё-таки это какой-то поиск? Вычитать всё, т.е. задача редкая и аналитическая - 0,1с на 260к строк вполне себе результат, на котором можно отстать от pg и заниматься своей аналитикой. Какой-то поискв реалтайме - то какой? Можно на помощь позвать jsquery, можно понаписать подходящий функциональный индекс. Надо понять, как отсечь максимум неподходящих данных за минимум усилий со стороны субд. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 12:04 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Melkij, >Но вам реально надо вычитать всё или всё-таки это какой-то поиск? Пока основная задача это дамп всех json в одну таблицу для переброски в elastic (там нет many-to-many). >Вычитать всё, т.е. задача редкая и аналитическая - 0,1с на 260к строк вполне себе результат, на котором можно отстать от pg и заниматься своей аналитикой. Сам запрос выполняется 15,2 - 15,4 секунды и это напрягает. 0,1 это видимо только построение развернутого запроса. >Какой-то поискв реалтайме - то какой? Пока поиска нет и врятли с ним будет проблема. >Надо понять, как отсечь максимум неподходящих данных за минимум усилий со стороны субд. Все данные нужны для переноса. А вот как переносить только новые данные - это еще один вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 12:11 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., explain analyze - это время уже с выполнением всего запроса. Построение только плана запроса - цифра Planning time и данные cost или просто explain, без analyze. Откуда вы наблюдаете 15 секунд? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 13:05 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Melkij, Если убрать explain, то 15 секунд я наблюдаю справа снизу в окне Query PgAdmin III (ставил отдельно от postgres). PostgreSQL 9.6.1 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit. Elastic при выполнении этого запроса в логах пишет тоже такое большое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 13:11 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., А если физически с той же машинки psql'ом? Не с сетью ли у вас проблемы. Explain по понятным причинам не учитывает время на передачу ответа по сети. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 13:18 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Melkij, а да действительно я же подключаюсь к удаленному серверу. Сейчас проверить скорость на localhost нет возможности, но если explain (analyze) правильно выводит время, поверю ему. А как тогда быстро передавать данные с сервера на сервер? 260к это же не очень много для сетевого подключения. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 13:29 |
|
Можно ли оптимизировать данный запрос с json
|
|||
---|---|---|---|
#18+
Andrew B., ну вот я и думаю, что с сетью именно проблема. Пакеты по пути слишком часто теряются, ошибки на самом интерфейсе, кто-нибудь хитрый зашейпил канал, MTU неправильно проставлен. Я не сетевик, чтобы точно диагностировать такие вещи. Чтобы точно отвязаться от PG поэкспериментируйте с простой передачей файлов туда-обратно. Если результат будет неадекватно медленный - то спросите в разделе по администрированию куда смотреть и что делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 14:10 |
|
|
start [/forum/topic.php?fid=53&fpage=80&tid=1996794]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
166ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 270ms |
0 / 0 |