explain.depesz.com

A tool for finding a real cause for slow queries.

Result: cxj

options
Did it help? Consider supporting us - Bitcoin address: 12v2hUztAk2LgzQ9H9LMwuU32urHMjZQnq
# exclusive inclusive rows x rows loops node
1. 0.036 127897.661 ↑ 7.7 26 1

Limit (cost=745.13..751.13 rows=200 width=43) (actual time=127891.917..127897.661 rows=26 loops=1)

2. 3.643 127897.625 ↑ 114.0 26 1

GroupAggregate (cost=745.13..834.05 rows=2964 width=43) (actual time=127891.915..127897.625 rows=26 loops=1)

3. 17.619 127893.982 ↓ 1.2 3421 1

Sort (cost=745.13..752.54 rows=2964 width=43) (actual time=127891.676..127893.982 rows=3421 loops=1)

  • Sort Key: c.entity_derived_type, c.display_name, c.entity_id, (lower((c.display_name)::text))
  • Sort Method: quicksort Memory: 350kB
4. 7.832 127876.363 ↓ 1.2 3421 1

Hash Left Join (cost=337.43..574.21 rows=2964 width=43) (actual time=127864.894..127876.363 rows=3421 loops=1)

  • Hash Cond: (a.id = b.user_id)
5. 3.831 3.831 ↓ 1.0 1823 1

Seq Scan on users a (cost=0.00..165.78 rows=1811 width=4) (actual time=0.011..3.831 rows=1823 loops=1)

  • Filter: ((retirement_date IS NULL) AND ((type)::text = 'HumanUser'::text))
6. 3.626 127864.700 ↑ 1.0 3113 1

Hash (cost=298.51..298.51 rows=3113 width=47) (actual time=127864.700..127864.700 rows=3113 loops=1)

  • Buckets: 1024 Batches: 1 Memory Usage: 166kB
7. 13.926 127861.074 ↑ 1.0 3113 1

Merge Left Join (cost=0.00..298.51 rows=3113 width=47) (actual time=0.703..127861.074 rows=3113 loops=1)

  • Merge Cond: (b.project_id = c.entity_id)
8. 4.427 4.427 ↑ 1.0 3113 1

Index Scan using sgcu_project_user_conn on project_user_connections b (cost=0.00..197.63 rows=3113 width=8) (actual time=0.019..4.427 rows=3113 loops=1)

9. 127842.721 127842.721 ↑ 2.6 3106 1

Index Scan using dneg_dnc_entity_id on display_name_caches c (cost=0.00..748135.70 rows=8039 width=43) (actual time=0.678..127842.721 rows=3106 loops=1)

  • Filter: ((c.entity_type)::text = 'Project'::text)