## Background Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/23629 `keeps/update_table_sizes.rb` keeps every table's `table_size` dictionary entry current from production sizes. It cannot classify a hash- or list-partitioned table correctly, and `issue_search_data` is the case that surfaced it: 227.49 GiB in total, largest partition 42.55 GiB, dictionary entry `small`. The cause is a schema mismatch between the keep and the `postgres_table_sizes` view: - `Keeps::Helpers::PostgresAi#fetch_postgres_table_size` selects `FROM postgres_table_sizes WHERE table_name = $1::text` — the bare table name, with no schema predicate. - The view is built over `pg_stat_user_tables` and keys on `(schemaname, relname)`, exposing `schema_name` alongside `table_name`. - Every partition of this table lives in the `gitlab_partitions_static` schema and is named `issue_search_data_00` … `_63`. The row whose `table_name` is exactly `issue_search_data` is the partitioned parent in `public`, which holds zero bytes. So the keep reads 0 bytes, `0 < 10 * 1024^3` classifies as `small`, and the entry is rewritten to `small` on every run. The dictionary rule it is meant to implement is the opposite: for a partitioned table the size is the size of the largest partition. This is not specific to one table. Any hash- or list-partitioned table whose partitions live in `gitlab_partitions_static` is classified from an empty parent, so the defect is systematic and silent — the keep reports success. ## Proposal Make the keep size a partitioned table by its largest partition. - In `fetch_postgres_table_size`, resolve a partitioned parent to `MAX(size_in_bytes)` across its partitions rather than reading the parent row. The view already carries `schema_name`, so the partition set is reachable without a new view. - Decide how partitions are identified. Matching on a name prefix is cheap and wrong at the edges (`issue_search_data` would also match a future `issue_search_data_archive`); joining `pg_inherits`/`pg_class` is correct but needs the view or the query widened. Pick one and say why in the merge request. - Note that `table_has_data?` has the same blind spot from the other direction: it runs `SELECT EXISTS (SELECT 1 FROM <table> LIMIT 1)` through the Rails connection, which does traverse partitions, so a partitioned table passes that check and then gets sized from an empty row. Do not "fix" `table_has_data?`. ## Done when - A partitioned table's dictionary entry is derived from its largest partition. - A test covers a hash-partitioned table whose parent is empty and whose largest partition exceeds the `small` threshold, and that test fails against the current implementation. A test that only passes proves nothing here, because the current code already passes for unpartitioned tables. - The run reports which partitioned tables changed classification, so the blast radius of the first corrected run is visible before it lands. ## Ownership `keeps/` and the classification thresholds belong to Database Frameworks, not to Global Search. This issue is filed under the epic because the epic found the defect; routing it needs a conversation with that group first, and the sequencing issue in this epic covers that. Do not assign it across group boundaries without one. ## Out of scope - Correcting the `issue_search_data` entry by hand. A sibling issue in this epic does that. - Changing the size thresholds in `fetch_postgres_table_size`. - Auditing which other partitioned tables are misclassified — worth doing, but it needs replica access and is a separate measurement. <details> <summary>Mechanism, citations, and what I did not verify</summary> ## Evidence Verified against `master` at commit `02c02def9c94a71fc1a0234e395c290354660966`: - [`keeps/helpers/postgres_ai.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/keeps/helpers/postgres_ai.rb) — the query, and the four-way `CASE` producing `small`/`medium`/`large`/`over_limit`. - [`keeps/update_table_sizes.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/keeps/update_table_sizes.rb) — `fetch_table_classification` takes `result.first` unconditionally. - `db/structure.sql` — `CREATE TABLE issue_search_data (...) PARTITION BY HASH (project_id)`, and 64 partitions under `gitlab_partitions_static`. - `db/structure.sql` — the `postgres_table_sizes` view definition, keyed on `pg_stat_user_tables.schemaname` and `relname`. - [`doc/development/database/database_dictionary.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) — "For partitioned tables, the size is the size of the largest partition." ## What I did not verify - That the parent row really reports 0 bytes on the production replica. The reasoning is from the view definition and `pg_total_relation_size` semantics on an empty parent relation, not from a query against production. - How many other partitioned tables are affected. </details>