cybertec-postgresql / pgwatch / 30320966560

86%

Build Type

push

github

Committed by web-flow

Commit Message

[*] migrate to time-only partitioning in pg sink (#1408)

* [*] remove partitionMapMetricDbname map and simplify EnsureMetricDbnameTime to EnsureMetricTimePartsExist

* [*] rename ensure_partition_metric_dbname_time to ensure_partition_metric_time and simplify to 2-level partitioning

* [-] remove drop_source_partitions function as dbname-level partitioning is removed

* [*] update README to reflect metric-time schema instead of metric-dbname-time

* [*] update partition tests to use metric-time schema (2-level partitioning)

* Implement the migration from LIST-partitioned metric to RANGE

Metrics tables created by older versions used LIST partitioning on the dbname
column. Since we now only use RANGE partitioning by time, we need to detect and
drop any LIST-partitioned table so the standard logic can recreate it with
the new partitioning strategy.

* Fix test

* rename migration

* simplify condition

* more test fixes

* Change `--partition-interval`'s default to `1 day`

* Use `admin.drop_all_metric_tables()` in the migration

instead of the old drop-on-write behaviour

* Preserve metric data during time-only partitioning migration

* add missing `FROM` keyword

* use `tx` instead of `conn` and make sure row is always returned

* bump the number of migrations

* try not to mix outer err with in-place err just in case

* list columns explicitly for future reference

* make `suffix` a const instead of reintroducing it at each iteration

* use explicit internal var for error in `BeginFunc`

* use one multi-statement query instead of several `tx.Exec` calls

* define consts for sql queries for easy reading

* use one multi-statement query instead of several `tx.Exec` calls

* add test case for migration

* handle identifiers safely

* Continue directly after finding an already migrated table

Instead of sending 2 additional unecessary queries.

---------

Co-authored-by: Pavlo Golub <pavlo.golub@gmail.com>

Coverage Stats

97 of 116 new or added lines in 1 file covered. (83.62%)

6 existing lines in 2 files now uncovered.

4775 of 5522 relevant lines covered (86.47%)

0.99 hits per line