# Continous transforms accumulating delay, can be tweak for speed up?

**URL:** <https://discuss.elastic.co/t/continous-transforms-accumulating-delay-can-be-tweak-for-speed-up/239807>\
**Category:** Elasticsearch\
**Created:** [July 3, 2020, 12:43pm UTC](https://discuss.elastic.co/t/continous-transforms-accumulating-delay-can-be-tweak-for-speed-up/239807 "2020-07-03T12:43:55Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![Germain\_Pavot](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/germain_pavot/32/71011_2.png) [@Germain\_Pavot](https://discuss.elastic.co/u/Germain_Pavot)\
**Post date:** [July 5, 2020, 9:37am UTC](https://discuss.elastic.co/t/continous-transforms-accumulating-delay-can-be-tweak-for-speed-up/239807/7 "2020-07-05T09:37:09Z")

</div>

I'am Idiot 🙂 I have modify the time range to :

```
"range": {
          "processed_at": {
            "gte": "now-2h/h"
          }
        }

```

So no modification needed on code, it's now really fast. The good strategy is for time base aggregation :

- At first create batches transforms for olds datas

- At end, modify transforms to :

And I suggest to elastic team the possibility of use "old checkpoint date" on query like that :

```
"range": {
          "processed_at": {
            "gte": "{{checkpoint}}-2h/h"
          }
        }

```

This will be more efficient (can set more aggressive time range) and more secure (if time is based on checkpoint and not on current date we avoid possibility of datas loose if transforms are throttle).

---

_[View the full topic](https://discuss.elastic.co/t/continous-transforms-accumulating-delay-can-be-tweak-for-speed-up/239807)._