It looks like time is not spent running the query but rendering the response due to the need to exclude very large fields from the response, which is expected if documents are very large. How large are the documents?
it is about 32MB. it was fine for not large files but customer needs use that size files, so it has to work with it. Possible in next release I can switch to something else than inject attachment?
@jpountz that's why I was expecting it to be faster when using only stored fields on "small" content. That said I might have missed that he is applying store: true on big fields as well which would explain then.
it became faster than it was before (150 ms is better than 300-500ms) but I have another bottleneck with nested field.
Using nested or parent/child is slowing down the execution. There might be some few things to make it a bit faster but it will never been as fast as unique documents.
Ok, I understand it. Is this thing a source includes fields or something else?
I don't understand the question.
How to make nested field in result hit faster when we have a big file content?
I don't know.
But you can denormalize your data and instead of indexing an array of attachments, just index attachments one by one and copy inside all the common fields.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.