Re: ACI Tree

On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira <
jdealmeidapereira(at)pivotal(dot)io> wrote:

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