Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1euWGd-0007wm-Mc for pgadmin-hackers@arkaria.postgresql.org; Sat, 10 Mar 2018 04:38:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1euWGb-000483-Ub for pgadmin-hackers@arkaria.postgresql.org; Sat, 10 Mar 2018 04:37:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1euWGb-00047t-De for pgadmin-hackers@lists.postgresql.org; Sat, 10 Mar 2018 04:37:57 +0000 Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1euWGX-0006l6-HH for pgadmin-hackers@postgresql.org; Sat, 10 Mar 2018 04:37:55 +0000 Received: by mail-oi0-x233.google.com with SMTP id e9so8553870oii.0 for ; Fri, 09 Mar 2018 20:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UbtXF+F6AwnAbuPYwAko8QtH7yjV/F5+K2fNgBbA2bM=; b=C3kUrFgW/sREjVsK+R9FrTv2euIHR5ucPcWTj6qG5A7DBpM5+be28t0pfhuHklDRaZ 9y7OaNm450V2qQSrWiDv3kSHcAPDUO1Iv8o4vZkbL7n7EXSBFNgSy6hVYTeTDe0Ml3eS 2dlAjcTC4oc95EAPyFSWJ1eUhW+qU7jjAGsH+KkoAin4nGnfnIPKjPlZfmK/nS917Sh0 ue0VHpH59QXuu4IduKNvKSd0/KXgbMTg0Q3tg2JygmA50kuO5hlgzFz3Vx/BCFpOQf6+ fxzq9NRx8XZi4XKC4fSNcDF9K6tzKTcHczaPmI88Z7ZKFYh7wpPEET69iNzEAixIcuUl 6Ehw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UbtXF+F6AwnAbuPYwAko8QtH7yjV/F5+K2fNgBbA2bM=; b=fb1BIvUAT/zojQFph3ZIM7WprLaxxL/TLzWxoZSdxmtd0YvuCuaFD5LLaZa74YEocZ y9Fh0Il7LkY8z7mJQpxkLSBwCi3O8MSzXcLQEs/uQNcM00/bpWliiFnxMIGjbJKE5onL 5n0hH/S4MJMU0pkHoGiCSyMKiulZNd/dXWAwrg30IaKAjNu9fgB8B5EMACrjm5vb7xnh 8Qc8WVPBwO5mEo00fG62+RhmtCr8vtaLNqtPbchU0VKH+qE5Ix8HbvovWjNbLp+kpcr5 mwbql1iDdQ0r7ctnqoapek0/dc8HEwiIQl5HgO6ZoOtiHVhcUci19rwRReLODSa7T5Ur J0Cg== X-Gm-Message-State: AElRT7HyIffZojUyx2lv2/GuCOiXqq1d+4B/OKlmcP/4j4S7fM8vByx/ PTx1qPOJ4Mx4ZiOdtZHfHkTbUJ9aaorYYd2bzm02wg== X-Google-Smtp-Source: AG47ELsxI3BsjR549+mb4WKzosDQyxACI9B4lSsOEF3h3h/yj4npd/sNu06hE2qCZpJ+ULrZGQSPhId8dh6r2gvqDXI= X-Received: by 10.202.63.85 with SMTP id m82mr547821oia.64.1520656672520; Fri, 09 Mar 2018 20:37:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.8.150 with HTTP; Fri, 9 Mar 2018 20:37:32 -0800 (PST) In-Reply-To: References: From: Murtuza Zabuawala Date: Sat, 10 Mar 2018 10:07:32 +0530 Message-ID: Subject: Re: ACI Tree To: Joao De Almeida Pereira Cc: pgadmin-hackers , Robert Eckhardt Content-Type: multipart/alternative; boundary="001a113dd492ca98380567077870" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a113dd492ca98380567077870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira < jdealmeidapereira@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 cod= e. > 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 th= at > 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 > =E2=80=8B +1=E2=80=8B > > 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 > =E2=80=8B > > > > On Wed, Mar 7, 2018 at 12:19 PM Robert Eckhardt > wrote: > >> Hackers, >> >> We have multiple end users who have in excess of 10 thousand of tables i= n >> 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 mo= re >> performant? >> >> -- Rob >> > --001a113dd492ca98380567077870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hi Hackers,
Maybe this list might not have a big group of us= ers of the application itself, nevertheless it would be interesting to unde= rstand if this is a specific problem of GreenPlum Use Case or not.
This issue is preventing a wider adoption of pgAdmin4 by the GreenPlum us= ers.

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:
    has_enable_triggers:"0"
  1. icon:"icon-table"
  2. id:&quo= t;table/831144"
  3. inode:true
  4. is_partitioned:false
  5. label:"act_20141008"<= /li>
  6. module:"pgadmin.node.table"=
  7. rows_cnt:= 0
  8. tigger_count:&qu= ot;0"
  9. = _id:8311= 44
  10. _pid:= 24579
  11. _type:"table"
- This am= ount of information take around 12 seconds to be displayed
- I= t is pretty hard to find something in set off 8k tables

<= /div>
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 o= ur code.=C2=A0
In order to try to create a better experience=C2= =A0 to these users these are the steps that we believe need to be done:

1 - Refactor the code so that it doesn't depend o= n the Tree to run
2 - See if this allows us to have an increased = performance.
3 - Instead of adding functionality to a Tree that d= oesn't look actively supported, maybe we should look into other trees t= hat are more actively being worked on
4 - Eventually replace the = tree with one that would allow us to have a smaller footprint and have func= tionalities 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:
=C2=A0- Detachment from the tree creating an adapter = layer that would eventually would allow us to swap tree if that is the case=
=C2=A0- Try to simplify the information returned by the backend<= /div>
=C2=A0- Stop piggybacking on the alias of requirejs to have thing= s done
=C2=A0- Steer us into a direction where adding a feature t= o the tree is something easy, testable and sustainable.

In a quick search we found 2 libraries that look interesting a= nd actively being developed:

Here are some= pros and cons on the libraries that we found:
react-virtualized-= tree:
Pros:
- Actively developed
- Search cap= abilities
- Users react virtualized, which looks very interesting= because it doesn't dump everything into the dom at once
Cons= :
- Single Committer
=E2=80=8B
+1= =E2=80=8B
=C2=A0
=

react-infinite-tree:
Pros:
- A= ctively 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
=E2=80=8B
=C2=A0


On Wed, Mar 7, 2018 at 12:19 PM Robert= Eckhardt <rec= khardt@pivotal.io> wrote:
Hackers,=C2=A0

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

The major issu= e 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?=C2=A0 Is there a solution better that (for some definition of better= than) replacing the ACI Tree with something more performant?
-- Rob

--001a113dd492ca98380567077870--