Re: ACI Tree

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 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

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 <reckhardt@pivotal.io> 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. 

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