# Sorting by CreationTime extremely slow **URL:** \ **Category:** Support\ **Created:** [May 17, 2024, 3:19pm UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372 "2024-05-17T15:19:31Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![msj242](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/msj242/32/340_2.png) [@msj242](https://forum.weaviate.io/u/msj242)\ **Post date:** [May 17, 2024, 3:19pm UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/1 "2024-05-17T15:19:31Z")
### Description This call below takes such a long time that it timesout. Even with long timeouts. I think this should be extremely fast seeing as though there is not even a hybrid search - this is just trying to get the last 10 items. It should be near instant, no? Perhaps I am using this wrong? Do I need to specify or add a creationTime index? Also I do have 100 million 384d objects. So it is a lot - but I assume I still must be missing something. ```auto let builder = this.client.graphql .get() .withClassName("Episode") .withFields("title, description, _additional{ id, creationTimeUnix }") .withLimit(options.limit) .withOffset(options.page * options.limit); builder = builder.withSort([{ path: ['_creationTimeUnix']}]) builder.do().then((res) => { console.log(res); }).catch((e) => { reject(e); }); ``` ### Server Setup Information - Weaviate Server Version: 1.24.12 - Deployment Method: Docker - Multi Node? Number of Running Nodes: 1 - Client Language and Version: Python/Go/Nodejs (Query in Nodejs) ### Any additional Information ```auto weaviate-weaviate-1 | {"action":"restapi_request","level":"debug","method":"POST","msg":"received HTTP request","time":"2024-05-17T15:11:29Z","url":{"Scheme":"","Opaque":"","User":null,"Host":"","Path":"/v1/graphql","RawPath":"","OmitHost":false,"ForceQuery":false,"RawQuery":"","Fragment":"","RawFragment":""}} weaviate-weaviate-1 | {"action":"request_cacher_dedup_joblist_start","jobs":1,"level":"debug","msg":"starting job list deduplication","time":"2024-05-17T15:11:29Z"} weaviate-weaviate-1 | {"action":"request_cacher_dedup_joblist_complete","jobs":1,"level":"debug","msg":"completed job list deduplication","removedJobs":0,"time":"2024-05-17T15:11:29Z"} weaviate-weaviate-1 | {"action":"request_cacher_dedup_joblist_start","jobs":1,"level":"debug","msg":"starting job list deduplication","time":"2024-05-17T15:11:29Z"} weaviate-weaviate-1 | {"action":"request_cacher_dedup_joblist_complete","jobs":1,"level":"debug","msg":"completed job list deduplication","removedJobs":0,"time":"2024-05-17T15:11:29Z"} ``` ---
**Author:** ![DudaNogueira](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/dudanogueira/32/7846_2.png) [@DudaNogueira](https://forum.weaviate.io/u/DudaNogueira)\ **Post date:** [May 17, 2024, 7:20pm UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/2 "2024-05-17T19:20:27Z")
hi @msj242 ! I believe that with that amount of objects, sharding your data in multiple nodes can help in this scenario. I will ask internally about this as this is an interesting case. Thanks! ---
**Author:** ![msj242](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/msj242/32/340_2.png) [@msj242](https://forum.weaviate.io/u/msj242)\ **Post date:** [May 17, 2024, 9:59pm UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/3 "2024-05-17T21:59:07Z")
@DudaNogueira Thanks! If so, I will look into sharding - As a patch, in the mean time I’ll keep a simple sqllite of recent uploads to speed things up for myself. ---
**Author:** ![DudaNogueira](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/dudanogueira/32/7846_2.png) [@DudaNogueira](https://forum.weaviate.io/u/DudaNogueira)\ **Post date:** [May 20, 2024, 2:28pm UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/4 "2024-05-20T14:28:22Z")
@msj242 one thing to consider: > **[Additional operators | Weaviate - Vector Database](https://weaviate.io/developers/weaviate/api/graphql/additional-operators#sorting-considerations)** > > Syntax > Weaviate does not use any sorting-specific data structures on disk. When objects are sorted, Weaviate identifies the object and extracts the relevant properties. This works reasonably well for small scales (100s of thousand or millions of objects). It is expensive if you sort large lists of objects (100s of millions, billions). In the future, Weaviate may add a column-oriented storage mechanism to overcome this performance limitation. So I believe that, when possible, filtering out a small dataset of objects, **and then sorting them out** can improve performance too. Let me know if this helps! Thanks! ---
**Author:** ![msj242](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/msj242/32/340_2.png) [@msj242](https://forum.weaviate.io/u/msj242)\ **Post date:** [June 4, 2024, 1:22am UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/5 "2024-06-04T01:22:09Z")
@DudaNogueira Thanks! I will keep this in mind in the future. ---
**Author:** ![VLSiddarth](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/vlsiddarth/32/7881_2.png) [@VLSiddarth](https://forum.weaviate.io/u/VLSiddarth)\ **Post date:** [May 9, 2026, 10:59am UTC](https://forum.weaviate.io/t/sorting-by-creationtime-extremely-slow/2372/6 "2026-05-09T10:59:34Z")
Dynamic date sorting and filtering at query time can easily choke the database under load. We hit the same timeout issues when trying to temporally sort high-velocity domains. To fix the latency, we moved the temporal math out of the vector DB entirely. Weaviate handles the raw semantic retrieval, and we pass the output through a dedicated temporal decay middleware (cached with Redis). It calculates the exact days\_until\_stale and applies an exponential decay curve in ~40ms, drastically reducing the load on the DB while ensuring the LLM only gets fresh context. Let me know if you want to see the architecture trace for this.