mirror of
https://github.com/penpot/penpot.git
synced 2026-11-05 19:53:15 -05:00
Andrey Antukh
d387c52b16
Partition `file_change` by `HASH (file_id)` in 16 partitions, with the same bounds as `file_data`, so a join between them is resolved partition by partition. The primary key becomes `(file_id, id)`, which a partitioned table needs, and every access filters by `file_id`. The new table carries a `kind` column (1 snapshot, 2 revision) as a reserve: the queries still tell them apart by the label, and `kind` takes over when they are rewritten. The payload of a snapshot stays in `file_data`; the `data` column is kept for reading old `legacy-db` payloads. The four snapshot commands require `file-id`, because it prunes the partition. The objects GC locks and deletes by the pair, in batches. The old table is kept as `file_change_legacy` as the way back. The automatic migration refuses to run above 10 GiB or 2M rows and points to the runbook; big instances partition online with that runbook, which copies by id, follows the `updated_at` watermark in delta passes and checks that no row of the source is missing from the target. Closes #12416 AI-assisted-by: deepseek-v4.1-flash
Operations
Procedures that are executed by hand on an instance, not by the application.
They are not part of the product: they describe how to do a one-off operation on a running database, with the exact statements to run and what to check between them.
Each procedure lives here while the operation is alive. When the operation is done, the file is either deleted or marked as historical, so the folder does not grow with procedures that nobody will run again.
| Procedure | Version |
|---|---|
Migrate legacy file payloads to file_data |
2.19.0 |
Partition file_change by file_id |
2.19.0 |