Alberto Islas

I tried different approaches related to the workaround mentioned in the issue comment. The main problem appears to be that **`index_phrases`** is not compatible with phrase highlighting because the query...

> But, roughly, how much faster are things without highlighting altogether? Sure, here are some numbers. I conducted various tests because the time it takes to highlight depends on the...

Two additional profiles should be performed in production; these are related to count queries so that we can determine how they impact the overall request time on prod [dockets_count_query.json](https://github.com/freelawproject/courtlistener/files/14438855/dockets_count_query.json) [fillings_count_query.json](https://github.com/freelawproject/courtlistener/files/14438854/fillings_count_query.json)

Great, thank you. I'll analyze the results and get back to you with my findings so we can start the sweep indexer.

@mlissner I've analyzed the profile responses and omitted the query profile that failed. At first sight, I thought there was something wrong with production because the profile sizes were huge...

I checked this one to confirm if we do need to do something in the V4 or V3 (ES) of the Search API. The search mentioned by @grossir does now...

> On the surface, that seems like a good idea to me, but it feels a lot like re-inventing Celery retries, doesn't it? Yeah it makes sense. I think there...

Sure! So you want me to check how we can retry tasks for all possible exceptions, including those not related to transient issues? I think those kind of errors could...

I'll start working on this one. Here are some notes about what we talked about today: - We're going to increase retries only on indexing tasks and give them a...

> It seems best to me to just do the reindexes in serial. Perfect, I agree. > I'm not sure what you mean about keeping the the "current document PK"...