Forum Discussion

PLMNewbie's avatar
PLMNewbie
Ideator II
20 days ago

Tree Grid View slow: reads whole branch on expand — improvement ideas?

 

Hi Aras Community Folks,

I’m facing a performance issue with the Aras TGV, expanding a node is extremely slow at large data volumes (~10 minutes at 1M items), and it looks like the server reads all descendant rows even though only the first 100 are shown. Details below — would really appreciate any guidance.

Environment: Aras Innovator 14.36(14 SP36). Standard TreeGridView over a recursive Query Definition.

Short version of the problem:
When a user expands a node, the grid shows only the first 100 children (page size 100, with a “Show More” row). But under the hood, the server reads every descendant item beneath that branch — hundreds of thousands of rows — even though only 100 are displayed and none of the descendants are returned in the response. At 1Million items this makes a single expand take ~10 minutes.

Root item (starting point)
│
└─ Level B item                      ← via root's reference property
   │
   ├─ [B → B]  Count(child B) > 0
   │     └─ Level B item   ⟲ "Reuse Query Element Definition" → back to B   (recursion)
   │
   └─ [B → C]  Count(C) > 0
         └─ Level C item   (is_current = 1)
            │
            └─ [C → C]  Count(C) > 0
                  └─ Level C item   ⟲ "Reuse Query Element Definition" → back to C   (recursion)

Page size (max_child_items) = 100   |   Default grow depth = 2
Two recursive legs: B→B and C→C, each gated by Count(...) > 0

  • Two recursive legs: B→B and C→C, each via Reuse Query Element Definition.
  • Each relationship is gated by a Count(...) > 0 child-existence filter.
  • TGV settings: page size max_child_items = 100, default grow depth = 2.

What we measured:

  • Expand one mid-level B node at 1M items: ~8 min. Shows 100 B rows + “Show More”, 0 C rows — but SQL reads the full descendant set (hundreds of thousands of rows) twice (paging query + property read).
  • Count(...) > 0 already compiles to a permission-aware EXISTS; the cost is the broad descendant read, tied to the expand-icon (hasChild) check.
  • Relationship source_id/related_id indexes already exist.

Questions:

  • On expand of an item, only the first 100 children are shown — but the server reads all descendants beneath the branch (full data) first, then returns 100 items. The descendants are read in full just to show 100 rows and to decide each row’s “+” expand icon. Is there a supported way to fetch only the 100 displayed rows from the start, and to make the expand-icon check stop at the first match instead of reading everything?
  • Regarding the global tgv_MaxFetchItemsCount variable (default 1,000,000): we’re considering temporarily lowering it (e.g. to 100) before an expand and restoring the default afterwards, to limit how much is fetched. Does it actually limit the result to that many rows (return just the first N), or does it only reject an over-limit request with an error? And is it checked before the heavy SQL runs (so it saves the work), or after (so the rows are already read)?

Would really appreciate any guidance or suggestions on the queries above

3 Replies

  • Hi,

    For this huge amount of data, do you really need a TGV?

    What is the practical use case where users can still interact with a TGV in a meaningful way when it contains 1 million items? Is there anything useful they can do with the TGV besides exporting the data to Excel?

    My questions are not intended to be provocative. I' m simply asking because, in most cases, a SQL query can solve the task much more efficiently than a TGV.

    I had a more or less similiar use case too solve some time ago. The amount of data was much smaller than yours, but the query was very complex and needed very long to render the TGV. I ended up using a SQL query and rendered the result in a "treegrid-like" view. 

    Tree Grid Views but with additional filters to hide data we don´t need - what options do we have? | Aras

    Best regards
    Angela

    • PLMNewbie's avatar
      PLMNewbie
      Ideator II

      Thanks again Angela for the reply so finally I tried an alternative to the SQL-based approach, I prototyped an AML-based path: a custom server method that replicates the Query Definition logic, plus a new TypeScript module in CodeTree providing a metadata-table template and a scoped TreeGrid.ts. The goal was to bypass the stock Aras rb_GetTreeGridData functionality.

      However, this approach carries meaningful risk. Replicating stock behavior means we have to re-implement concerns that Aras handles for us — security/permission enforcement being the main one — and get them exactly right. It also hurts maintainability: because it effectively replaces an existing Query Definition with hand-written code, every future change (adding a relationship or a property) would require editing CodeTree files rather than simply updating the QD.

      Given that trade-off, I consider replacing the existing QD too risky to pursue as the primary solution. 

  • Thanks a lot Angela for the reply. From what I understood of the requirement, the end user should be able to filter down to a specific tag and see the relationship it has with parent/child BOM, as well as other areas like classification and version. End users usually would have data around 1M items, so it is difficult when the designed TGV can't scale up.

    When you say SQL query, do you mean a custom render backed by SQL, or pairing a SQL view with a federated item type that the TGV points to? Also — in your linked thread your SQL approach gave a flat view (Level / Document / Parent columns) and you mentioned it didn't show the intermediate levels.

     Did you eventually get it to render as an actual tree with the intermediate BOM levels, or is it still the flat table? If you got the tree working, how did you render it, and did it hold up at larger data volumes?