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

Only send fields specified in YQL up from content nodes #3404

Open
frodelu opened this issue Sep 13, 2017 · 3 comments
Open

Only send fields specified in YQL up from content nodes #3404

frodelu opened this issue Sep 13, 2017 · 3 comments

Comments

@frodelu
Copy link
Member

frodelu commented Sep 13, 2017

As seen in VESPA-9043 (and numerous other times), it can be unnecessarily expensive (primarily network wise) when the content nodes return the full default summary class (all fields) when only a subset of the fields were requested in the YQL query.

While I understand the technical reason for this, it's not logical to the user that they need to create a separate summary class in addition to specifying this in the YQL select statement. Is it possible for us to add list of fields to be sent down along with query and get an "automatic summary class" returned?

@frodelu frodelu added this to the later milestone Sep 13, 2017
@bratseth
Copy link
Member

Implementation note:
We want to do this over RCP only,
so it depends on enabling RPC for summary fetch by default,
which depends on the capability of serializing the query tree over RPC.

Perhaps about a work package amount of work in total, for 2 persons.

@baldersheim
Copy link
Member

I think is not necessary to require that. The path in the backend is the same and no real protocol changes are needed. The summary class sent down is a string. Just send down a comma separated list of fields. The backend can then look up if the strings are a summary class or not.

It is not only the query we need to bring along, at least location and rankproperties etc, are on the side. I would prefer to at least move location inside the querytree where it belongs. insteda of bringing our mistakes with us over in the new protocol.

Also, if you specify ranking.queryCache the query is not needed.
So I would say this one does not have any blockers.

@bratseth
Copy link
Member

Yes, we could implement it also in the old protocol if it becomes critical to do this fast. It's preferable not to though.

@geirst geirst added this to To Do in Search and content Sep 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

3 participants