public inbox for [email protected]
help / color / mirror / Atom feedACI Tree
3+ messages / 3 participants
[nested] [flat]
* ACI Tree
@ 2018-03-07 17:19 Robert Eckhardt <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Robert Eckhardt @ 2018-03-07 17:19 UTC (permalink / raw)
To: pgadmin-hackers
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: ACI Tree
@ 2018-03-09 20:34 Joao De Almeida Pereira <[email protected]>
parent: Robert Eckhardt <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Joao De Almeida Pereira @ 2018-03-09 20:34 UTC (permalink / raw)
To: pgadmin-hackers; +Cc: Robert Eckhardt <[email protected]>
--001a1147ce1467c7ee056700b8b6
Content-Type: text/plain; charset="UTF-8"
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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: ACI Tree
@ 2018-03-10 04:37 Murtuza Zabuawala <[email protected]>
parent: Joao De Almeida Pereira <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Murtuza Zabuawala @ 2018-03-10 04:37 UTC (permalink / raw)
To: Joao De Almeida Pereira <[email protected]>; +Cc: pgadmin-hackers; Robert Eckhardt <[email protected]>
On Sat, Mar 10, 2018 at 2:04 AM, Joao De Almeida Pereira <
[email protected]> 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 <[email protected]>
> 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
>>
>
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2018-03-10 04:37 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-03-07 17:19 ACI Tree Robert Eckhardt <[email protected]>
2018-03-09 20:34 ` Joao De Almeida Pereira <[email protected]>
2018-03-10 04:37 ` Murtuza Zabuawala <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox