Conversation
…k score set deletion Deleting a score set cascades through SQLAlchemy to delete each of its variants, and Postgres checks every foreign key into variants.id to enforce referential integrity on each one. score_calibration_functional_classification_variants carries variant_id only as the trailing column of its composite primary key (functional_classification_id, variant_id), so that check has no index it can use and instead sequentially scans the whole table once per variant being deleted. The table is global, growing with every calibration ever created across MaveDB, so the cost compounds with both the deleted score set's variant count and the table's total size. This is the mechanism behind #677 ("unpublished score set deletion often fails"): deletion runs synchronously in the request, and for any score set with a nontrivial number of variants the per-variant sequential scan is slow enough to time out, non-deterministically depending on how large the association table has grown. Confirmed with EXPLAIN against a synthetic 200k-row table: the FK check plan flips from Seq Scan to Index Scan, and deleting 500 variants drops from ~2.6s to ~2.4ms. The migration builds the index CONCURRENTLY, outside a transaction, since the table may already be large enough in production that a blocking build would itself be disruptive.
Coverage Report for CI Build 35640332294Warning No base build found for commit Coverage: 88.971%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsRequires a base build to compare against. How to fix this → Coverage Stats
💛 - Coveralls |
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #677.
score_calibration_functional_classification_variantscarriesvariant_idonly as the trailing column of its composite primary key(functional_classification_id, variant_id). Postgres has no index it can use to check that FK when aVariantrow is deleted, so it sequentially scans the whole table once per variant — and that table is global, growing with every calibration ever created across MaveDB. Deleting a score set cascades to deleting each of its variants synchronously in the request, so for any score set with a nontrivial number of variants this dominates the delete and is slow enough to time out, non-deterministically depending on how large the association table has grown.Confirmed with
EXPLAINagainst a synthetic 200k-row association table: the FK check plan flips fromSeq ScantoIndex Scan, and deleting 500 variants drops from ~2.6s to ~2.4ms.The migration builds the index
CONCURRENTLY, outside a transaction, since the table may already be large enough in production that a blocking build would itself be disruptive.