### Summary `Database::PartitionManagementWorker` decides whether to `ANALYZE` a partitioned table by checking the **first leaf partition's** `last_analyze`, not the parent's. After `gitlab-ctl pg-upgrade`, `vacuumdb --analyze-in-stages` analyzes every leaf partition but skips partitioned parents. The worker sees a fresh leaf timestamp and skips the parent. For the CI tables (`analyze_interval: 3.days`) this leaves `p_ci_builds`, `p_ci_pipelines`, `p_ci_stages`, and others without parent statistics for up to 3 days after an upgrade. That causes poor query plans, high disk I/O, and timeouts on pipeline pages. The check was written to support PostgreSQL versions before 14, which did not track `last_analyze` for partitioned tables. The minimum version is now 17 (`Gitlab::Database::MINIMUM_POSTGRES_VERSION`), so the worker can check the parent directly. ### Steps to reproduce On PostgreSQL 17: 1. Create a partitioned table with data: ```sql CREATE TABLE p_t (id int, part int) PARTITION BY LIST (part); CREATE TABLE p_t_1 PARTITION OF p_t FOR VALUES IN (1); CREATE TABLE p_t_2 PARTITION OF p_t FOR VALUES IN (2); INSERT INTO p_t SELECT g, 1 + g % 2 FROM generate_series(1, 10000) g; ``` 1. Run what `gitlab-ctl pg-upgrade` runs: `vacuumdb --all -j2 --analyze-in-stages`. 1. Check `pg_stat_get_last_analyze_time(oid)` and `pg_statistic` rows for each relation. 1. Run `ANALYZE (SKIP_LOCKED) p_t;` (what the worker runs) and check again. Result (PostgreSQL 17.11): ```plaintext -- after vacuumdb relname | relkind | last_analyze_set | pg_statistic_rows p_t | p | f | 0 p_t_1 | r | t | 2 p_t_2 | r | t | 2 -- after ANALYZE (SKIP_LOCKED) p_t p_t | p | t | 2 ``` After step 2, the worker's check (`pg_stat_get_last_analyze_time` on the first partition) returns a recent time, so `ineligible_for_analyzing?` is true and the parent is not analyzed. Step 4 shows that the parent's own `last_analyze` is available on current PostgreSQL versions. ### Example Project Not applicable. ### What is the current *bug* behavior? After a PostgreSQL major upgrade, partitioned parent tables have no statistics. The worker skips them until the first leaf partition's `last_analyze` is older than `analyze_interval` (3 days for CI tables). The default interval from #624175 and #630895 uses the same check. ### What is the expected *correct* behavior? The worker sees that the parent was never analyzed and runs `ANALYZE` on its next run, within 6 hours (`21 */6 * * *`). ### Relevant logs and/or screenshots Seen on a self-managed Linux package instance after `gitlab-ctl pg-upgrade`. The PostgreSQL log shows `vacuumdb` analyzing leaf partitions (for example `gitlab_partitions_dynamic.ci_builds`) right after the upgrade. For the next ~40 hours, it shows no `ANALYZE` of any partitioned parent, although the worker runs every 6 hours. A manual `ANALYZE` fixed the performance immediately. Zendesk ticket (For internal use only): https://gitlab.zendesk.com/agent/tickets/756122 ### Output of checks Not applicable. ### Possible fixes In [`last_analyzed_at_within_interval?`](https://gitlab.com/gitlab-org/gitlab/-/blob/bb5a3400c0ea3d9aae225b6b79080b395313b7cb/lib/gitlab/database/partitioning/partition_manager.rb#L316-328), query the parent table instead of `first_model_partition`, and remove the pre-PostgreSQL 14 comment: ```ruby last_analyzed_at = connection.select_value( "SELECT pg_stat_get_last_analyze_time(#{connection.quote(model.table_name)}::regclass)" ) ``` Update the related examples in `spec/lib/gitlab/database/partitioning/partition_manager_spec.rb`. Trade-off: after this change deploys, parents that were never analyzed through the parent are analyzed on the next worker run. The same happens once after every major upgrade. The worker analyzes tables one at a time with a 1 hour statement timeout, so this adds load for one run. #630895 made the same choice for default-interval tables and kept this out of `db:migrate`. Related: - #423135 (scheduled `ANALYZE` of partitioned tables) - #624175 and #630895 (default `analyze_interval` for all partitioned tables) - omnibus-gitlab docs MR: https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/9837 ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).