| From: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Erratically behaving query needs optimization |
| Date: | 2019-08-22 17:43:10 |
| Message-ID: | 1566495790294-0.post@n3.nabble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marco Colli | 2019-08-22 17:54:57 | Re: Extremely slow count (simple query, with index) |
| Previous Message | Michael Lewis | 2019-08-22 17:37:04 | Re: Extremely slow count (simple query, with index) |