pgAdmin4 performance - Mailing list pgadmin-support

Hi

Just had a look at pgAdmin4. Looks very nice but I'm having some issues 
with performance for the kind of use that our office will use it for.

If you take a table like this which we use quite a lot (we are a survey 
business, nowadays I would have used jsonb)

CREATE TABLE a870m1
(  id integer,  frameid integer,  s156 integer,  s157 integer,  s300 integer,  s235 integer,  s178a integer,  s178b
integer, s178c integer,  s178d integer,  s178e integer,  s178f integer,  s178g integer,  a87001a integer,  a87001b
integer, a87001c integer,  a87001d integer,  a87001e integer,  a87001f integer,  a87001g integer,  status1 text,  s116
integer, v015509 integer,  v015510 integer,  v015498 integer,  v015499 integer,  v015500 integer,  v015501 integer,
v015502integer,  v015503 integer,  v015504 integer,  v015505 integer,  v015507 integer,  v015508 integer,  s161a
integer, s161b integer,  s161c integer,  s161d integer,  s161e integer,  s161f integer,  s161g integer,  s161h integer,
s161i integer,  s161j integer,  s161k integer,  s161l integer,  s161m integer,  s301 integer,  v015515 integer,
v015517integer,  v015518 integer,  v015519 integer,  v015520 integer,  v015521 integer,  v015522 integer,  v015527
integer, v015528 integer,  v015526 integer,  v015523 integer,  v015524 integer,  v015525 integer,  v015560 integer,
v015561integer,  v015562 integer,  v015563 integer,  v015513 integer,  s151 integer,  s121 integer,  s122 integer,
s123integer,  s124 integer,  v015514 integer,  v015640 integer,  v015641 integer,  s302 integer,  v015529 integer,
v015530integer,  v015537 integer,  v015538 integer,  v015539 integer,  v015540 integer,  v015541 integer,  v015542
integer, v015543 integer,  v015668 integer,  v015567 integer,  v015600xc1 text,  v015600xc2 text,  v015531 integer,
v015533integer,  v015534 integer,  v015535 integer,  v015570 integer,  v015571 integer,  v015572 integer,  v015573
integer, s150a integer,  v015545 text,  v015546 integer,  v015550 integer,  v015547 integer,  v015547xc text,  s108
integer, v015549 integer,  v015549xc text,  s174 integer,  s174xc text,  how_completed text,  sys_pop_weight numeric,
sys_sam_weightnumeric,  nho text,  gender text,  ethnicity text,  tenancy_type text,  sys_respondent_group
sys_respondent_group, sys_respondent_sub_group sys_respondent_sub_group,  survey_id integer,  respondent_key bigint,
sys_sampleinteger,  replied integer
 
)
WITH (  OIDS=FALSE
);

CREATE INDEX a870m1_replied_ndx  ON a870m1  USING btree  (replied)  WHERE replied = 1;


And populate it with 30,000 rows.

In pgAdmin 1.22.1 it takes:

12 seconds to View All Data.

29 seconds to select * from a870hack in query window made up of:-  12 seconds of query (timer running in status window)
17 seconds of apparent inactivity. I presume this is column size 
 
algorithm as in earlier versions  there was no such wait. This in itself has caused problems for my 
users (constant moaning about performance).

In pgAdmin4 it takes:

46 seconds to View All Data but then it takes:  9 seconds to view page 2  4 seconds to view any subsequent page

31 seconds to select * from a870hack in query window and then we are 
back to:-  9 seconds to view page 2  4 seconds to view any subsequent page


It looks to me the problem lies in the smart column sizing algorithm 
being way too expensive in terms of time.

Anyway as always thanks for all the effort you put in to produce these 
tools.

Kieran