If you want to improve the collapsing performance, you might use a numeric
supplier id to collapse on instead of a string.
You've denormalized things, which is typically the right trade-off. As you
have observed, the down-side is that you have to reindex lots of stuff when
a related entity changes
Hi all,
Any help here, wrt above mentioned details?
*Thanks & Regards,*
*Uday Kumar*
*Product Search Tech*
On Mon, Mar 17, 2025, 19:24 Uday Kumar wrote:
> Hi,
>
>
> *Please find details below:*In our index, we have data of suppliers along
> with their products which we display on front-end, wr
Hi,
*Please find details below:*In our index, we have data of suppliers along
with their products which we display on front-end, wrt search requests.
*Example: For a supplier with id: 678, we have 2 products in our index*
*product-id(unique)*
*document1:*
{
product-id: 123
product-price: 2000r
Hi Uday,
Your email is a perfect example of
https://en.m.wikipedia.org/wiki/XY_problem.
Both for indexing and query time you need to explain your problems and use
cases rather than your attempted solutions.
Then we'll be able to give some recommendations.
On Wed, 5 Mar 2025, 06:39 Uday Kumar,
Hi,
I would like to give some extra context here, so that it would help in
getting better suggestions
*Our goal:To improve our search system either by optimizing indexing or by
improving solr response times*
*Current approach while indexing at our end:*
Even with change in a single field of docu
Also in place updates happen on very specific conditions, have you checked
you satisfy them before even attempting to see some sort of impact on your
use case?
Yes we considered those specifications, here, we didnt mean to say it's not
impactful in itself. but with our project & schema
*Thanks & R
What is your problem? Rather than asking about a solution you attempted is
usually better to start from the problem.
You talk about grouping, have you considered field collapsing?
According to my experience going with nested documents rarely justify the
performance and functional overhead both at
Does this mean it will not be impactful in performance to use Nested
Indexing in production with such an indexing rate?
We have tried POC on inplace updates and found its not impactful either wrt
our project, so we would not be using this in combination too
*Thanks & Regards,*
*Uday Kumar*
*Produ
Changing one child rewrites the whole block period.
However in-place updating child docValues is promising in theory, although
I don't know how it works in practice.
On Thu, Feb 27, 2025 at 8:05 AM Uday Kumar
wrote:
> Hi all,
> We are doing a POC on indexing nested documents in expectation of re
