esselitowE
Convex Community•3mo ago•
1 reply
esselitow

Aggregate component heavy on database-bandwidth

❔Advice🧩component
I have an aggregate on 
orders
 table, which is like the main table for the application I've built. An order can have a status (number), a type (id of another table), a partner (id of another table) and it can also be invoiceStatus (number)

So my aggregate composes of all 4 of them as keys because the users need to be able to filter using the 4 values and be able to see how many in that filter exists, this gives them an important overview of their work, upcoming tasks etc.

The actual query for getting the orders is paginated, so it's quick and has very low database-bandwidth, but the aggregate is using more than 10x (yes really) more than the order query. It is still quick but I guess it's not scalable and will at some point be slower then the order query.

I am looking for any help or suggestions, I've read through the docs alot and used the AI chat.

The query is first doing a initiation:
    const params: {
      bounds: {
        prefix:
          | [number]
          | [number, boolean]
          | [number, boolean, string]
          | [number, boolean, string, string];
      };
    }[] = [];


And then adding to that, so that it can do a 
countBatch
 at the end. AFAIK and reading through the docs, using the 
countBatch
 is the most efficient way, and the way to do it best is to first have logic to stick everything inside a array, and then call 
countBatch
 once. Since this was introduced I have seen improvements i the aggregate, but it is still heavy.

Now I am thinking of using Namespaces, but talking to the AI and reading the docs, it doesn't seem like they give any benefit if the thing that is namespaced on isn't clearly a separation from eachother, which it is not in this case because they are all orders.

The orders update alot.

Any help or suggestion is welcome!
Was this page helpful?