Closed illusional closed 1 year ago
Explain plan: Looks like it's filtering on an index batches_time_completed, so should filter and sort quickly.
batches_time_completed
-> Limit: 51 row(s) (cost=308316.58 rows=51) (actual time=0.074..0.520 rows=51 loops=1) -> Nested loop inner join (cost=308316.58 rows=92069) (actual time=0.072..0.515 rows=51 loops=1) -> Nested loop left join (cost=276092.43 rows=92069) (actual time=0.063..0.475 rows=51 loops=1) -> Nested loop left join (cost=180570.84 rows=92069) (actual time=0.049..0.296 rows=51 loops=1) -> Nested loop left join (cost=79778.30 rows=92069) (actual time=0.043..0.191 rows=51 loops=1) -> Filter: (batches.deleted = 0) (cost=47554.15 rows=92069) (actual time=0.032..0.147 rows=51 loops=1) -> Index range scan on batches using batches_time_completed, with index condition: (batches.time_completed is not null) (cost=47554.15 rows=184138) (actual time=0.030..0.140 rows=51 loops=1) -> Single-row index lookup on billing_projects using PRIMARY (name=batches.billing_project) (cost=0.25 rows=1) (actual time=0.000..0.001 rows=1 loops=51) -> Single-row index lookup on batches_n_jobs_in_complete_states using PRIMARY (id=batches.id) (cost=0.99 rows=1) (actual time=0.002..0.002 rows=1 loops=51) -> Single-row index lookup on batches_cancelled using PRIMARY (id=batches.id) (cost=0.94 rows=1) (actual time=0.003..0.003 rows=0 loops=51) -> Single-row index lookup on billing_project_users using PRIMARY (billing_project=batches.billing_project, user='$USER') (cost=0.25 rows=1) (actual time=0.001..0.001 rows=1 loops=51)
Explain plan: Looks like it's filtering on an index
batches_time_completed
, so should filter and sort quickly.