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 127,897.661 ↑ 7.7 26 1

Limit (cost=745.13..751.13 rows=200 width=43) (actual time=127,891.917..127,897.661 rows=26 loops=1)

2. 3.643 127,897.625 ↑ 114.0 26 1

GroupAggregate (cost=745.13..834.05 rows=2,964 width=43) (actual time=127,891.915..127,897.625 rows=26 loops=1)

3. 17.619 127,893.982 ↓ 1.2 3,421 1

Sort (cost=745.13..752.54 rows=2,964 width=43) (actual time=127,891.676..127,893.982 rows=3,421 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 127,876.363 ↓ 1.2 3,421 1

Hash Left Join (cost=337.43..574.21 rows=2,964 width=43) (actual time=127,864.894..127,876.363 rows=3,421 loops=1)

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

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

  • Filter: ((retirement_date IS NULL) AND ((type)::text = 'HumanUser'::text))
6. 3.626 127,864.700 ↑ 1.0 3,113 1

Hash (cost=298.51..298.51 rows=3,113 width=47) (actual time=127,864.700..127,864.700 rows=3,113 loops=1)

  • Buckets: 1024 Batches: 1 Memory Usage: 166kB
7. 13.926 127,861.074 ↑ 1.0 3,113 1

Merge Left Join (cost=0.00..298.51 rows=3,113 width=47) (actual time=0.703..127,861.074 rows=3,113 loops=1)

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

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

9. 127,842.721 127,842.721 ↑ 2.6 3,106 1

Index Scan using dneg_dnc_entity_id on display_name_caches c (cost=0.00..748,135.70 rows=8,039 width=43) (actual time=0.678..127,842.721 rows=3,106 loops=1)

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