Subject: ACI Tree

From: Robert Eckhardt <[email-masked]>
Date: Wed, 7 Mar 2018 12:19:29 -0500

Hackers,

We have multiple end users who have in excess of 10 thousand of tables in a
single schema. Currently this causes pgAdmin to choke.

The major issue we are seeing is that the ACI tree is unsupported and it
seems to be the backbone of pgAdmin 4.

Is anyone else having this issue?  Is there a solution better that (for
some definition of better than) replacing the ACI Tree with something more
performant?

-- Rob

---

From: Joao De Almeida Pereira <[email-masked]>
Date: Fri, 09 Mar 2018 20:34:24 +0000

Hi Hackers,
Maybe this list might not have a big group of users of the application
itself, nevertheless it would be interesting to understand if this is a
specific problem of GreenPlum Use Case or not.
This issue is preventing a wider adoption of pgAdmin4 by the GreenPlum
users.

---

From: Murtuza Zabuawala <[email-masked]>
Date: Sat, 10 Mar 2018 10:07:32 +0530

On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira <
[email-masked]> wrote:

> From a preliminary investigation we found the following:
> - When we try to retrieve 8k tables from the backend we get a payload of
> 3.3Mb with the following information:
>
>    1. has_enable_triggers:"0"
>    2. icon:"icon-table"
>    3. id:"table/831144"
>    4. inode:true
>    5. is_partitioned:false
>    6. label:"act_20141008"
>    7. module:"pgadmin.node.table"
>    8. rows_cnt:0
>    9. tigger_count:"0"
>    10. _id:831144
>    11. _pid:24579
>    12. _type:"table"
>
> - This amount of information take around 12 seconds to be displayed
> *- It is pretty hard to find something in set off 8k tables*
>
> We started looking into possibilities to solve this issue, but we bumped
> into the ACI Tree again and the way ACI Tree is so ingrained into our code.
> In order to try to create a better experience  to these users these are
> the steps that we believe need to be done:
>
> 1 - Refactor the code so that it doesn't depend on the Tree to run
> 2 - See if this allows us to have an increased performance.
> 3 - Instead of adding functionality to a Tree that doesn't look actively
> supported, maybe we should look into other trees that are more actively
> being worked on
> 4 - Eventually replace the tree with one that would allow us to have a
> smaller footprint and have functionalities like search already embedded.
>
> The last time we tried to take a look at ACI Tree we started by trying to
> create a new Tree and see if we could plug it in the current code, and that
> approach was not successful, so we believe that this new approach might
> gain us the following:
>  - Detachment from the tree creating an adapter layer that would
> eventually would allow us to swap tree if that is the case
>  - Try to simplify the information returned by the backend
>  - Stop piggybacking on the alias of requirejs to have things done
>  - Steer us into a direction where adding a feature to the tree is
> something easy, testable and sustainable.
>

>
> In a quick search we found 2 libraries that look interesting and actively
> being developed:
> https://www.npmjs.com/package/react-virtualized-tree
> https://www.npmjs.com/package/react-infinite-tree
>
> Here are some pros and cons on the libraries that we found:
> react-virtualized-tree:
> Pros:
> - Actively developed
> - Search capabilities
> - Users react virtualized, which looks very interesting because it doesn't
> dump everything into the dom at once
> Cons:
> - Single Committer
>
​
+1​

>
> react-infinite-tree:
> Pros:
> - Actively developed
> - Search capabilities
> Cons:
> - Single Committer
>
> ACI Tree:
> Pros:
> - Already in the code
> Cons:
> - No longer maintained
> - No website with documentation
> - No search
> - Heavy
>
> Thanks
> Joao
> ​
>
>

>
> On Wed, Mar 7, 2018 at 12:19 PM Robert Eckhardt <[email-masked]>
> wrote:
>
>> Hackers,
>>
>> We have multiple end users who have in excess of 10 thousand of tables in
>> a single schema. Currently this causes pgAdmin to choke.
>>