Quantcast
Channel: TimescaleDB and PostgreSQL - Timescale Community Forum
Viewing all articles
Browse latest Browse all 291

5 second planning for updating a single row. Execution 0.8 ms

$
0
0

Hi

I currently have a hypertable with ~5 billion rows. I have set compression to 3 weeks prior to DeliveryStartUTC column which is of type timezone. I have data from a few years back and 5 years in the future. I rarely write back in time. This setup gives me 297 chunks. When I try to write some time in the future with a query like this:

EXPLAIN ANALYZE
UPDATE public."DataPoints"
SET "TimeRegisteredUTC" = '2025-01-27 08:44:43.506065Z'
WHERE "DeliveryStartUTC" = '2026-09-01 03:45:00Z'
AND "Id" = 21011571099

It takes several seconds due to the planner being very slow. This is the query plan:

Custom Scan (HypertableModify)  (cost=0.43..2.66 rows=1 width=18) (actual time=0.724..0.725 rows=0 loops=1)
  ->  Update on "DataPoints"  (cost=0.43..2.66 rows=1 width=18) (actual time=0.724..0.725 rows=0 loops=1)
        Update on _hyper_26_24547_chunk "DataPoints_1"
        ->  Result  (cost=0.43..2.66 rows=1 width=18) (actual time=0.084..0.086 rows=1 loops=1)
              ->  Index Scan using _hyper_26_24547_chunk_idx_datapoints_update on _hyper_26_24547_chunk "DataPoints_1"  (cost=0.43..2.65 rows=1 width=10) (actual time=0.083..0.085 rows=1 loops=1)
                    Index Cond: (("DeliveryStartUTC" = '2026-09-01 03:45:00+00'::timestamp with time zone) AND ("Id" = '21011571099'::bigint))
Planning Time: 5322.877 ms
Execution Time: 0.844 ms

As you can tell, it is using an index to find the correct row and execution time is fast. However, planning time is crazy high. Even with an index on DeliveryStartUTC and Id which it seems to utilize.

Any suggestions on how to fix this?

5 posts - 2 participants

Read full topic


Viewing all articles
Browse latest Browse all 291

Trending Articles