François Massot

Thanks for the report. I moved the json parsing and document building out of the benchmark and I still see almost a factor of two between array VS no array...

oh yes sorry for my lack of accuracy, @PSeitz you indeed mentioned the solution of having a dedicated endpoint for OpenSearch. > Mapping interval to fixed_interval is only an option...

@PSeitz Just to confirm that I did not find other queries with an API difference between Elasticsearch en OpenSearch for the `airmail` project. I had a look at the following...

@PSeitz do you need more info on your side?

For `airmail`, we need to support: `\d+s`, `\d+m`, `\d+h`. I think we can only support what we support currently for the `fixed_interval`. On `OpenSearch`, you can have a look at...

you mean `1d` was date-aware in elasticsearch? So to avoid issues, we could only support `ms`, `s`, `m`, `h` and avoid the problematic `d`.

Ok, I have just understood how this was broken before... I thought the issue was only on `1d` when reading the comment you quoted previously. Moreover, I saw yesterday in...

Hi @savannahar68 You can have several approaches. First simple approach... you have a document with one field `body` where you put all the text. In the logs space, generally, engineers...

thanks @mosuka! Using other punctuation marks like the dot '.' might be useful too. Or let the user handle it. [vibrato](https://github.com/daac-tools/vibrato) seems interesting to get insights on perf improvements.

should we merge this PR and open a follow-up issue then?