explain.depesz.com

A tool for finding a real cause for slow queries.

Result: WgQ

options
Did it help? Consider supporting us - Bitcoin address: 12v2hUztAk2LgzQ9H9LMwuU32urHMjZQnq
# exclusive inclusive rows x rows loops node
1. 33,264.953 49,970.470 ↓ 1.3 11,208,288 1

Nested Loop (cost=1,242.67..109,948.80 rows=8,557,568 width=61) (actual time=198.011..49,970.470 rows=11,208,288 loops=1)

2. 50.227 255.629 ↓ 1.5 728 1

Nested Loop (cost=1,242.67..1,986.35 rows=488 width=45) (actual time=197.974..255.629 rows=728 loops=1)

  • -> Index Scan using idx_sensor_dpoint_id on sensor s (cost=0.00..0.28 rows=1 width=45) (actual time=0.009..0.010 rows=0 loops=32
3. 110.852 205.402 ↓ 1.3 3,280 1

HashAggregate (cost=1,242.67..1,267.49 rows=2,482 width=8) (actual time=197.899..205.402 rows=3,280 loops=1)

  • Index Cond: (dpoint_id = l.dpoint_id)
  • Filter: (building_id = 3)
4. 94.550 94.550 ↑ 1.0 62,066 1

Seq Scan on locator l (cost=0.00..1,086.74 rows=62,374 width=8) (actual time=0.013..94.550 rows=62,066 loops=1)

5. 16,449.888 16,449.888 ↑ 1.1 15,396 728

Materialize (cost=0.00..1,036.70 rows=17,536 width=16) (actual time=0.002..22.596 rows=15,396 loops=728)

  • -> Index Scan using idx_time_ny_local_key on time_ny t (cost=0.00..949.02 rows=17536 width=16) (actual time=0.023..32.438 rows=1
  • Index Cond: ((local_key >= 201202260000::bigint) AND (local_key <= 201204191155::bigint))