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(at)pivotal(dot)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
>