chore(tradein/db): уборка временных таблиц, дублей индексов и звёздочки в v_data_quality #2746

Merged

lekss361 merged 1 commit from chore/tradein-db-cleanup into main

2026-08-06 18:27:40 +00:00

lekss361 commented

2026-08-06 17:19:35 +00:00

Owner

Волна 0 инвентаризации техдолга. Две миграции, обе только убирают лишнее.

Миграция 222 — уборка

Временные таблицы разовой чистки 02.07 — tmp_purged_junk_houses_0702, tmp_purged_junk_links_0702 (2.9 МБ). Зависимостей нет, проверено.

Пять строгих дублей индексов. Каждый дублирует UNIQUE-ограничение по тому же набору колонок в том же порядке:

Таблица	Сносим	Остаётся	Сканов у сносимого
`agents`	`agents_source_ext_idx`	`agents_ext_source_ext_agent_id_key`	2
`ekb_geoportal_buildings`	`ix_ekb_geoportal_buildings_street_house`	`..._street_norm_house_norm_key`	13 945
`house_placement_history`	`hph_source_item_idx`	`..._source_ext_item_id_key`	0
`house_reviews`	`hr_source_ext_idx`	`..._source_ext_review_id_key`	15
`sellers`	`sellers_source_idx`	`sellers_source_ext_seller_id_key`	2

Аудит предполагал шесть — нашлось ровно пять, проверено тремя независимыми способами (нормализованный DDL, indkey/indoption/opclass через pg_index). Расхождение зафиксировано намеренно, а не подогнано.

Два похожих кандидата НЕ тронуты — oph_listing_time_idx и hpd_house_dim_idx. Там смешанный порядок (ASC, DESC), недостижимый обратным сканом UNIQUE-индекса — тот же класс исключения, что и уже задокументированные idx_lss_source_date / listings_snapshots_listing_date_idx.

v_data_quality — пересоздана с явным перечислением колонок вместо SELECT *. Сейчас звёздочка тянет 92 зависимости от listings, что мешает менять таблицу. Поведение представления не меняется.

Миграция 225 — индекс под внешний ключ

listing_source_snapshots(run_id) — внешний ключ без индекса на таблице в 3,2 млн строк. Создаётся CONCURRENTLY, поэтому файл намеренно без BEGIN/COMMIT.

Проверено, что это безопасно: applier в deploy-tradein.yml вызывает psql -v ON_ERROR_STOP=on без --single-transaction, то есть транзакцию не навязывает. Прецеденты уже применены на проде без BEGIN/COMMIT: 003_seed_deals.sql, 005_geocode_tracking.sql, 218_scrape_runs_ban_kind.sql, 223_scrape_runs_time_columns_meaning.sql.

Проверка

Обе миграции прогнаны на прод-БД внутри BEGIN … ROLLBACK, тело дважды: первый проход выполняет, второй — сплошные already exists / does not exist, skipping. SELECT из пересозданного представления возвращает валидные данные.

Состояние прода после прогона проверено отдельно и независимо: временные таблицы на месте, все пять индексов на месте, idx_lss_run_id не создан, v_data_quality — 16 колонок и 92 зависимости, то есть не изменена, в _schema_migrations записей нет. Ничего не закоммичено.

pytest — 3904 passed, 10 skipped, 0 failed. Тесты манифеста миграций 4/4.

Номера

222 и 225. Сверены не только по main, но и по всем удалённым веткам (~300) — сегодня коллизия префиксов ловилась четырежды, причём последний раз именно от соседнего открытого PR. Во время работы в main влился #2547 (занял 229/231) — пересверено после ребейза, пересечений нет.

Волна 0 инвентаризации техдолга. Две миграции, обе только убирают лишнее. ## Миграция 222 — уборка **Временные таблицы разовой чистки 02.07** — `tmp_purged_junk_houses_0702`, `tmp_purged_junk_links_0702` (2.9 МБ). Зависимостей нет, проверено. **Пять строгих дублей индексов.** Каждый дублирует UNIQUE-ограничение по тому же набору колонок в том же порядке: | Таблица | Сносим | Остаётся | Сканов у сносимого | |---|---|---|---| | `agents` | `agents_source_ext_idx` | `agents_ext_source_ext_agent_id_key` | 2 | | `ekb_geoportal_buildings` | `ix_ekb_geoportal_buildings_street_house` | `..._street_norm_house_norm_key` | 13 945 | | `house_placement_history` | `hph_source_item_idx` | `..._source_ext_item_id_key` | **0** | | `house_reviews` | `hr_source_ext_idx` | `..._source_ext_review_id_key` | 15 | | `sellers` | `sellers_source_idx` | `sellers_source_ext_seller_id_key` | 2 | Аудит предполагал шесть — нашлось ровно пять, проверено тремя независимыми способами (нормализованный DDL, `indkey`/`indoption`/`opclass` через `pg_index`). Расхождение зафиксировано намеренно, а не подогнано. **Два похожих кандидата НЕ тронуты** — `oph_listing_time_idx` и `hpd_house_dim_idx`. Там смешанный порядок `(ASC, DESC)`, недостижимый обратным сканом UNIQUE-индекса — тот же класс исключения, что и уже задокументированные `idx_lss_source_date` / `listings_snapshots_listing_date_idx`. **`v_data_quality`** — пересоздана с явным перечислением колонок вместо `SELECT *`. Сейчас звёздочка тянет **92 зависимости от `listings`**, что мешает менять таблицу. Поведение представления не меняется. ## Миграция 225 — индекс под внешний ключ `listing_source_snapshots(run_id)` — внешний ключ без индекса на таблице в 3,2 млн строк. Создаётся `CONCURRENTLY`, поэтому **файл намеренно без `BEGIN`/`COMMIT`**. Проверено, что это безопасно: applier в `deploy-tradein.yml` вызывает `psql -v ON_ERROR_STOP=on` **без** `--single-transaction`, то есть транзакцию не навязывает. Прецеденты уже применены на проде без `BEGIN`/`COMMIT`: `003_seed_deals.sql`, `005_geocode_tracking.sql`, `218_scrape_runs_ban_kind.sql`, `223_scrape_runs_time_columns_meaning.sql`. ## Проверка Обе миграции прогнаны на прод-БД внутри `BEGIN … ROLLBACK`, тело дважды: первый проход выполняет, второй — сплошные `already exists / does not exist, skipping`. `SELECT` из пересозданного представления возвращает валидные данные. **Состояние прода после прогона проверено отдельно и независимо:** временные таблицы на месте, все пять индексов на месте, `idx_lss_run_id` не создан, `v_data_quality` — 16 колонок и 92 зависимости, то есть не изменена, в `_schema_migrations` записей нет. Ничего не закоммичено. `pytest` — 3904 passed, 10 skipped, 0 failed. Тесты манифеста миграций 4/4. ## Номера 222 и 225. Сверены не только по `main`, но и по **всем** удалённым веткам (~300) — сегодня коллизия префиксов ловилась четырежды, причём последний раз именно от соседнего открытого PR. Во время работы в `main` влился #2547 (занял 229/231) — пересверено после ребейза, пересечений нет.

lekss361 added 1 commit 2026-08-06 17:19:36 +00:00

chore(tradein/db): уборка временных таблиц, дублей индексов и звёздочки в v_data_quality

CI / changes (pull_request) Successful in 8s

Details

CI Trade-In / changes (pull_request) Successful in 8s

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

CI Trade-In / backend-tests (pull_request) Successful in 3m23s

Details

1b758f5e63

- DROP tmp_purged_junk_houses_0702 / tmp_purged_junk_links_0702 (снэпшот чистки
  02.07, 2.9 МБ, без зависимостей — проверено на проде)
- DROP 5 строгих дублей индексов (agents/ekb_geoportal_buildings/
  house_placement_history/house_reviews/sellers) — hph_source_item_idx с нулём
  сканов среди них; idx_lss_source_date и listings_snapshots_listing_date_idx
  НЕ тронуты (mixed ASC/DESC порядок, недостижим сканом pkey, #2607)
- v_data_quality: явный список из 6 колонок вместо `SELECT * FROM listings`
  в CTE — было 89 паразитных column-level зависимостей, мешавших чистить
  listings; поведение view не изменилось
- CREATE INDEX CONCURRENTLY под FK listing_source_snapshots.run_id (2.87М
  строк, 696 MB, до этого Seq Scan на каждый DELETE из scrape_runs)