quickwit-oss / quickwit-oss/quickwit

[refactoring] Find a solution to avoid deserializing the query_ast over and over

Open
#5,287 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Rust
Stars
11.7k
Forks
597
Avg merge
2d 22h
Merged PRs (30d)
37

Description

Right now, for convenience, we directly use the search request proto object as our model for the search request.

The query ast is serialized as JSON in it.
We end up deserializing/modify/reserializing it a lot during search.

It would be nice to do some refactoring to avoid this.

e.g.


#[derive(Clone)]
pub struct SearchRequest {
    pub query_ast: Arc<QueryAst>,
    search_request_proto: SearchRequestProto
}


impl TryFrom<SearchRequestProto> for SearchRequest {
    type Error = anyhow::Error;

    fn try_from(search_request_proto: SearchRequestProto) -> Result<Self, Self::Error> {
        let query_ast: Arc<QueryAst> = serde_json::from_str::<QueryAst>(&search_request_proto.query_ast)
            .context("invalid query ast")?
            .into();
        Ok(SearchRequest {
            query_ast,
            search_request_proto,
        })
    }
}

impl Deref for SearchRequest {

    type Target = SearchRequestProto;

    fn deref(&self) -> &SearchRequestProto {
        &self.search_request_proto
    }
}


impl DerefMut for SearchRequest {
    fn deref_mut(&mut self) -> &mut SearchRequestProto {
        &mut self.search_request_proto
    }
}

or pushing the JSON serialization / deserialization of the QueryAST into the message using a custom message implementation. (We need to make sure to make it an Arc to make sure a copy of the AST is not too heavy)

or using a different model object for the search request

or breaking the search request into several different models.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how SearchRequestProto, QueryAst, and the search request are created and mutated during search. Compare the proposed wrapper, custom message serialization, separate model, and split-model options; done means the chosen design avoids repeated QueryAst serialization while preserving request behavior and safe shared ownership.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, search
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.