Skip to content

Hashed Storage: Force migration to Hashed Storage via background jobs

What does this MR do?

Force migration to Hashed Storage via background jobs

Database performance

explain SELECT COUNT(*) FROM "projects" WHERE ("projects"."storage_version" < 2 OR "projects"."storage_version" IS NULL)

Plan with execution:

Aggregate  (cost=13.00..13.01 rows=1 width=8) (actual time=75.732..75.733 rows=1 loops=1)
   Buffers: shared hit=205 read=42 dirtied=10
   I/O Timings: read=73.458
   ->  Index Only Scan using index_on_id_partial_with_legacy_storage on public.projects  (cost=0.27..12.62 rows=153 width=0) (actual time=2.792..75.656 rows=254 loops=1)
         Heap Fetches: 22
         Buffers: shared hit=205 read=42 dirtied=10
Summary:
Time: 76.335 ms
  - planning: 0.532 ms
  - execution: 75.803 ms
    - I/O read: 73.458 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 205 (~1.60 MiB) from the buffer pool
  - reads: 42 (~336.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 10 (~80.00 KiB)
  - writes: 0

Conformity

Availability and Testing

Impact is similar to when running it from command line. This will query for every non-migrated project, in batches of 200, and schedule them to be migrated.

Closes #246655 (closed)

Edited by Gabriel Mazetto

Merge request reports

Loading