Skip to content

Batch number field lookups in Dirichlet character search columns - #7175

Open
roed-math wants to merge 3 commits into
LMFDB:mainfrom
roed-math:ai/t29-dirichlet-col-batch
Open

Batch number field lookups in Dirichlet character search columns#7175
roed-math wants to merge 3 commits into
LMFDB:mainfrom
roed-math:ai/t29-dirichlet-col-batch

Conversation

@roed-math

Copy link
Copy Markdown
Contributor

Closes #6008.

The kernel field and value field columns added in #6004 issued two database queries per row each (an nf_fields lookup by coefficients plus an nf_fields_extra lookup), 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_fields query; 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 $or of equalities rather than $in, because psycodict omits the ::numeric[] typecast on the array-$in path.


Ported from roed-math#41, where the full write-up and comment history live.

🤖 Generated with Claude Code

roed314 and others added 3 commits July 19, 2026 14:33
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Speed up kernel and value fields in search results

2 participants