Hi everyone, I am noticing a strange latency issue when using any filters/sort by when using group by. We have a product_variants collection, which have product variants that can be grouped by their product id. We make use of group_by: "productID", group_limit: 1 in almost all our search queries. We recently upgraded to V27 and were doing some load testing. We've noticed that adding any sort_by, or filter_by spikes up the search time by a lot. Here's the examples: Without any sort by:

/collections/vaaree_product_variants/documents/search?q=*&group_by=productID&query_by=searchText0%2CsearchText1%2CsearchText2&group_limit=1&per_page=1&include_fields=id

search time in the response:

"search_time_ms": 0

With sort by price:

/collections/vaaree_product_variants/documents/search?q=*&group_by=productID&query_by=searchText0%2CsearchText1%2CsearchText2&group_limit=1&per_page=1&include_fields=id&sort_by=price%3Adesc

search time in response

"search_time_ms": 91

This is very consistently 91 milliseconds. This is the most simple query I can make, returning only the id, no complex filters or sort bys. 91ms seems a lot for this search. Any idea what's happening here?

What's the value of the

found

field in response?

Without sort by

"found": 1,
    "found_docs": 61986,
    "out_of": 61986,

With sort by

"found": 47856,
    "found_docs": 61986,
    "out_of": 61986,

Sort by should not affect found number. Are you able to reproduce on a small dataset.

Yes, we have another collection which has 501 docs. When using sort by

found

is 66 and when not using sort by found is 1. I think the behaviour with sort by is correct here? We rely on found to figure out how many search results are possible for a given query, to enable pagination and what not. If found is returned as 1 and found docs returns the total number of documents matching (which would be greater than the actual results because of group by), we would have no way to determine number of products (i.e groups) matching a given query.

Sort by should not affect found. Please share the dataset and the exact query, we can check that's happening.

I am not sure how I can share the data set with you. We are on typesense cloud, so would sharing the cluster id and collection name be enough?

Yes

I have messaged you with the details, TIA 👍

For wildcard queries without a sort by,, we default to sorting by an internal unique ID that's assigned to each document. Since documents on-disk are already stored in a pre-sorted form on this order, we could just get the first N records based on pagination parameters. However, this shortcut won't work for group by so should not do that here. I will fix it.

Okay thanks for the info! Does that fix the found mismatch or the 91ms latency thing?

Found mismatch.

are you running it in the

vaaree_product_variants

collection with group by and sort by both? I am still seeing >90 milli seconds:

"search_time_ms": 93

Yes

Strange, I am consistently seeing it as >90. This is the query I am running:

curl --location '<baseUrl>/collections/vaaree_product_variants/documents/search?q=*&group_by=productID&query_by=searchText0%2CsearchText1%2CsearchText2&group_limit=1&per_page=1&page=1&sort_by=price%3Adesc' \
--header 'x-typesense-api-key: <apiKey>'