On Thu, Mar 5, 2026 at 2:23 AM Mikhail Khludnev <[email protected]> wrote:
> it occurs in the real coordinator data-less node. It's caused by awkward
> flow when Query Component triggers query parsing even if it will throw away
> the lucene query parsed because stepping into distributed process (fan out
> per-shards reqs). It would be great to redesign this old flaw. Another
> part of the trouble is that JoinQP is too eager - checking indices on
> parsing despite the query will be thrown away in a coordinator node.
> Meanwhile I'll think about quickly hacking JoinQP to make it lazy
> deferring query creation.

Agreed... this is a design flaw of Solr.  A SearchHandler (and thus
all SearchComponents) doing the distributed search (we might call
this, "acting as the coordinator") should ideally not have access to a
SolrCore yet still have access to things like the schema & solrconfig
& some other things.  An ex-colleague of mine was kind of exploring
this a year ago.  I'd love to see a redesign.

It's remarkable that SearchHandler & SearchComponents have survived
intact (with no major changes) for about 15 years.  Yet writing a
SearchComponent (or debugging one) for distributed search is pretty
complicated / confusing -- the design isn't documented and is
non-obvious.

~ David

Reply via email to