Re: It takes a long time for pgAdmin to retrieve database schema details - Mailing list pgadmin-support

From Little, Douglas
Subject Re: It takes a long time for pgAdmin to retrieve database schema details
Date
Msg-id 8585BA53443004458E0BAA6134C5A7FB0C64C56C@EGEXCMB01.oww.root.lcl
Whole thread Raw
In response to It takes a long time for pgAdmin to retrieve database schema details  (顾小波 <guxiaobo1982@gmail.com>)
List pgadmin-support

We run pgadmin 3 10.0- 10.0.3 on GP 3.3.6 running on 10node solaris x64 10u3 array.   Our db has 158 schema, the largest (350 tables, + 350 external tables),  4000+ tables,  some tables with 2000+ (not desirable) partitions.  Whole db size is ~12.5tb.

Pgadmin will take a long time connecting on 1st run.   After that, it seems to have a lot of data cached,  so connections usually take < 3sec but can take up to 20sec.

 

Doug

 

 

From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of ???
Sent: Wednesday, July 14, 2010 10:49 AM
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] It takes a long time for pgAdmin to retrieve database schema details

 

 

Hi,

 

we use gpAdminIII 1.10.3 with Greeenplum database 3.3.5.0 on Solaris X64 10u7, one of our databases has 36 schemas, one of which has 716 tables, and the whole database size is about 4~5T. When users open pgAdminIII and click the database node under the Databases node it takes a long time for pgAdminIII to “restoring previous environment….”, when users click one of the schemas, it also takes a long time for pgAdminIII to “retrieving Schema details…”, and the whole Interface is haling, I think this is due to this operation is single threaded. Another suggestion is can you improve gpAdmin to retrieve as little detail information as possible, just to retrieve it when user really need it, especially for high cost operations such as select count(*) from table.

 

Xiaobo Gu

pgadmin-support by date:

Previous
From: Michael Shapiro
Date:
Subject: Re: Bug with exceptionally long values.
Next
From: Jeff Adams
Date:
Subject: Re: Bug with exceptionally long values.