On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira < jdealmeidapere...@pivotal.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 <reckha...@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 >> >
