| От | legrand legrand |
|---|---|
| Тема | Re: Erratically behaving query needs optimization |
| Дата | |
| Msg-id | 1566495790294-0.post@n3.nabble.com обсуждение исходный текст |
| Ответ на | Re: Erratically behaving query needs optimization (Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com>) |
| Список | pgsql-performance |
Hello,
1/ access scheduler_task_executions
by index with device_id = 97
seems ok
2/
I don't understand why
joining
scheduler_task_executions.id=scheduler_operation_executions.task_execution_id
is done using a parallel hash join
when a nested loop would be better (regarding the number of rows involved)
maybe because index on scheduler_operation_executions.task_execution_id
"index_task_execution_id_desc" btree (task_execution_id DESC NULLS LAST)
is not usable or bloated or because of DESC NULLS LAST ?
3/ join with results.operation_execution_id
by index
seems OK
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера