|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Добрый день. Подскажите в чем может быть ошибка? Не знаю с чего начать, поэтому начну от проблемы. Такой запрос выполняется нормально, быстро примерно 125ms Код: plsql 1. 2. 3.
Следующий запрос не выполняется, точнее заканчивается неудачно по таймауту: Код: plsql 1. 2. 3.
Отличается только выбираемым значением dport=1025 Следующий запрос выполняется быстро: Код: plsql 1. 2. 3.
Отличается от предыдущего отсутствием вложенного запроса (datetime >= '2017-03-17') СУБД postgres (PostgreSQL) 9.4.10 Код: 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.
Код: plsql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 09:43 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
itoeng, планы выполнеия каждого из запросов что показывают? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 09:47 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Так что ли? 1 запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
2 запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
3 запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 10:46 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Извиняюсь за форматирование поста выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 10:48 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
itoeng, попробуйте переписать в виде datetime >= now()::date, т.е. без подзапроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 10:56 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Alexius, Гениально. Спасибо большое, это решило проблему. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 11:02 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
itoeng, есть ещё и такой литерал даты: Код: sql 1.
он в планах ведёт себя лучше now()::date. -- фича, думаю, в том , что литералы "исчисляются " до планирования. как и иммутабные значения. правда ли оно, и чем чревато при смене суток (т.е. в какой момент определяется current_timestamp транзакции -- на начало планирования или на начало исполнения) -- надо думать/тестировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 11:20 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
qwwq, Спасибо, буду знать. Вообще по началу использовал date_trunc ('day' , now()), но когда освоил EXPLAIN заметил что стоимость запроса с ним выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 11:35 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
а чего у вас адреса varchar'овые, а не inet ? Для показанных запросов напрашивается индекс dport & src & datetime или src & dport & datetime. Надо смотреть другие запросы, какой порядок смогут использовать и другие запросы тоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 12:13 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Melkij, Не знал что так можно, приму к сведению. Первый раз делаю проект такого уровня. Набиваю шишки. С индексами возился месяц назад, сначала делал связанные несколькими полями, но работало плохо, возможно как раз проблема была во вложенном запросе. Но добился стабильной работы сделав несвязанные несколькими полями. Расскажите, если не трудно, в чем преимущество предложенного вами индекса? Пока у меня есть три запроса генерируемых из POST запросов из веб страницы CGI. Код: plsql 1. 2. 3. 4.
Код: plsql 1. 2. 3. 4. 5.
Код: plsql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 13:29 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Проблема была, вероятно, в порядке полей в индексе. Для btree он критично важен. Сейчас ваш запрос вычитывает хвост индекса по дате, затем лезет в таблицу за соответствующими строками, чтобы выбросить все строки, не подходящие под остальные условия. Второй explain как раз показывает, что планировщик решил не идти по индексу по дате, вместо этого bitmap'ом пройтись по индексам по src и номеру порта. А составной индекс позволяет быстренько по индексу пройти и прочитать строки уже подходящие под условия src и dport. Шикарно описано вот тут: http://use-the-index-luke.com/ С такими 3 запросами можно оставить составной индекс по src, datetime. Затем уже при необходимости по src, dport, datetime. Сейчас похоже данных не много и индекс src & datetime будет достаточно селективен и сам по себе. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2017, 13:52 |
|
Странное поведение при использовании вложенного запроса
|
|||
---|---|---|---|
#18+
Melkij , спасибо за разъяснения. Попробовал сделать составной индекс src, datetime с таким индексом запросы выполняются заметно быстрее. Еще несколько вопросов: 1 Подскажите как, будет происходить такое преобразование данных на живой БД ? Можно ли вообще это делать на живой? или лучше на время приостановить insert`ы? Код: plsql 1. 2. 3.
2 Я так понимаю после преобразования, для фактического изменения размера БД, надо будет выполнять ANALYZE, VACUUM. Так ли это? 3 Надо ли после преобразования выполнять перестройку индексов или они будут перестраиваться автоматически во время выполнения преобразования? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2017, 21:43 |
|
|
start [/forum/topic.php?fid=53&fpage=77&tid=1996647]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
95ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 204ms |
0 / 0 |