Batch number field lookups in Dirichlet character search columns - #7175
Open
roed-math wants to merge 3 commits into
Open
Batch number field lookups in Dirichlet character search columns#7175roed-math wants to merge 3 commits into
roed-math wants to merge 3 commits into
Conversation
…DB#6008) The kernel field and value field columns each issued two database queries per row (nf_fields lookup by coefficients plus a nf_fields_extra lookup inside WebNumberField.from_coeffs/from_cyclo), about 200 round trips per 50-row results page. Add a postprocessing step to the search that computes all defining polynomials up front (the pari galoissubcyclo/polredabs computations take ~9ms per page) and finds the matching number field labels in a single nf_fields query; the column display functions use the precomputed labels and fall back to the old per-row behavior when they are absent. The batch query uses a top-level $or of equality clauses because psycodict's array $in path omits the ::numeric[] typecast that plain equality gets. Verified: rendered results tables byte-identical before/after on four sample searches; render time 29.3/29.5/14.4/24.6s -> 0.45/0.85/0.90/0.89s against devmirror; downloads unchanged by construction; 26 character tests pass (including a new test_field_columns); pyflakes clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…DB#6008) The batched postprocessing step kept only the label of each matched number field, so formatfield built a WebNumberField holding just that label and field_pretty reloaded the record from the database whenever the pretty name needed more than the label: degree 3 wants disc_abs/disc_sign/coeffs, generic degree 4 and degree 2^k want subfields/subfield_mults. Displaying the kernel field 4.0.2197.1 (the order 4 characters of modulus 13) therefore still made 5 record level lookups, so a cold results page did database work proportional to the number of distinct kernel fields on it. Keep the whole nf_fields record in character_postprocess (one query either way) and hand it to formatfield as the virtual column kernel_field_data. Every column field_pretty consults lives in nf_fields, so no nf_fields_extra batch is needed. Case 5b of field_pretty also looked up the unique quadratic subfield of an imprimitive quartic by coefficients; read the squarefree radicand off the stored subfield polynomial instead, the way cases 5a and 7 already do, which leaves no lucky/lookup call in the render path. Verified: 5 record lookups -> 0 when displaying that kernel field, and 0 over a 50 row page of order <= 12 characters; the new test_field_columns_no_lookups patches nf_fields.lookup, nf_fields.lucky and nf_fields_extra.lookup to raise and fails on the previous commit; rendered results tables and downloads are byte identical before and after on 9 searches and 4 downloads; old and new case 5b radicands agree on the 1450 quartics with a unique quadratic subfield among the 4000 smallest discriminant quartics; cold render of ?modulus=1-500&order=4&showcol=first drops from 11.2s to 0.9s, order=8 from 7.9s to 0.9s and order=3 from 4.5s to 0.9s against devmirror. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Closes #6008.
The kernel field and value field columns added in #6004 issued two database queries per row each (an
nf_fieldslookup by coefficients plus annf_fields_extralookup), roughly 200 round trips per 50-row results page.This adds a postprocessing step to the search that computes all defining polynomials up front and finds the matching number field labels in a single
nf_fieldsquery; the column display functions use the precomputed labels, falling back to the old per-row behavior if the data is absent.Profiling shows the pari computations (galoissubcyclo/polredabs) take ~9ms per page, so the database round trips were the entire cost, answering the question raised in the issue. Rendered search-results tables are byte-identical before and after on sample searches, downloads are unchanged, and page render time against a remote database drops from 14-30s to under 1s (16-65x).
The batch query uses
$orof equalities rather than$in, because psycodict omits the::numeric[]typecast on the array-$inpath.Ported from roed-math#41, where the full write-up and comment history live.
🤖 Generated with Claude Code