Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search and add queries that use Lucene specific optimizations #1

Open
fulmicoton opened this issue Aug 31, 2018 · 5 comments
Open

Search and add queries that use Lucene specific optimizations #1

fulmicoton opened this issue Aug 31, 2018 · 5 comments

Comments

@fulmicoton
Copy link
Collaborator

No description provided.

@fulmicoton
Copy link
Collaborator Author

added a query that benefits heavily from the two step queries.

@usamec
Copy link

usamec commented Nov 20, 2018

@fulmicoton any deeper description about what is exactly going on here? (link to some lucene documentation is enough).

@fulmicoton
Copy link
Collaborator Author

fulmicoton commented Nov 20, 2018

Right... So Lucene introduced two step queries a long time ago. The idea is that scorer can express that they have some notion of .advanceWithFalsePositives() that is cheap and a checkIfReallyInDocset() function that is expensive to compute.

This is typically the case for a phrase query. .advanceWithFalsePositives() is typically just an intersection of the terms. checkIfReallyInDocset() requires to decode positionos and check if the terms align correctly somewhere in the document.

Now something interesting happens when running the query "a b" AND c.
The two step query system makes it possible to only decode positions for document that contain C.

If you scroll down in the benchmark that's precisely why added the query +"the who" +uk which is the hero scenario for this (because the and who are frequently in the same document.).
Lucene is indeed outperforming tantivy on that kind of query.

It would be interesting to find other kinds of examples

@usamec
Copy link

usamec commented Nov 20, 2018

Thanks, and is tantivy planning to add this?

@fulmicoton
Copy link
Collaborator Author

Yes at one point. But right now, I don't think the extra complexity is worth the performance boost on specific queries. If a performance critical user shows up, I'll be happy to reproritize.

It's however a good idea to list these corner case where Lucene is faster than tantivy and show them in the bench.

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

No branches or pull requests

2 participants