Repository navigation
Speed up the readiness tree's beam destination exclusion - #56
Merged
Merged
Conversation
The readiness page's tree took 15 to 30 seconds per level with a beam destination excluded, against under a second without one, on a database with 7,000 components in the included destination. The exclusion added to filter_system_status, which the tree runs once per system at every level, was a NOT IN subquery inside the function's CASE expression. Oracle cannot rewrite a subquery in that position into a join, so it evaluated it as a filter on every row, and the plan it cached for it was an index skip scan of the whole component_beam_destination primary key with an LNNVL filter: about 200 block reads per row. Replace it with a NOT EXISTS correlated on the component id, which gives the optimizer a unique probe of the primary key for each row whatever the statistics say. filter_category_child_table gets the same form for consistency, although Oracle already rewrote its OR form well. Existing databases need the two create or replace statements, given in the pull request. Measured on the dev stack with 7,000 synthetic components (16 destination memberships each, all but 255 in the excluded destination) and gathered statistics, include 9 and exclude 13: the root node went from 14.8 s to 0.1 s, the first level from 30.3 s to 0.8 s and the second from 20.6 s to 0.7 s, with the same nodes and statuses. Without an exclusion the levels take 0.1 to 0.3 s either way. Part of #46 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
slominskir
approved these changes
Oct 28, 2026
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
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.
Follow-up to #53 for #46: the readiness page's tree took 15 to 30 seconds per level with a beam destination excluded, against under a second without one, on a database with 7,000 components in the included destination (the reports from #54 were fine).
The exclusion in
filter_system_status, which the tree runs once per system at every level, was aNOT INsubquery inside the function'sCASEexpression. Oracle cannot rewrite a subquery in that position into a join, so it evaluated it as a filter on every row, and the plan it cached was an index skip scan of the wholecomponent_beam_destinationprimary key with anLNNVL(component_id <> :B1)filter, about 200 block reads per row. This pull request replaces it with aNOT EXISTScorrelated on the component id, which gives the optimizer a unique probe of the primary key per row whatever the statistics say.filter_category_child_tablegets the same form for consistency, although Oracle already rewrote itsORform into an indexedNOT EXISTS. The Java side is unchanged.Upgrade steps
Existing databases need the two
create or replacestatements below, fromcontainer/oracle/initdb.d/02_ddl.sql(a new Oracle container frombuild.yamlgets them on creation).SQL for existing databases