Re: refreshRow is slow
От | Oliver Jowett |
---|---|
Тема | Re: refreshRow is slow |
Дата | |
Msg-id | 4B50F92D.5020403@opencloud.com обсуждение исходный текст |
Ответ на | Re: refreshRow is slow ("John T. Dow" <john@johntdow.com>) |
Ответы |
Re: refreshRow is slow
Re: refreshRow is slow |
Список | pgsql-jdbc |
John T. Dow wrote: > Following that, where my program would do the refreshRow on the original resultset, I find a 21 instances of this block(some lines omitted): > > 17:25:50.812 (1) simple execute, handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@1142196, maxRows=0,fetchSize=0, flags=17 > 17:25:50.812 (1) FE=> Parse(stmt=null,query="SELECT attname FROM pg_catalog.pg_attribute WHERE attrelid = $1 AND attnum= $2",oids={23,23}) > 17:25:50.812 (1) FE=> Bind(stmt=null,portal=null,$1=<16404>,$2=<1>) This is a metadata query, getting the canonical name of each field/column in your resultset so that updateRow() knows how to build the refresh query. > 17:38:47.031 (1) selecting select id, address, citystatezip, combined, degree, email, fax, firstname, groupname, lastname,nfiid, pabsid, practicetype, ssn, telephone, insertby, insertdate, inserttime, updateby, updatedate, updatetimefrom doctor where id= ? > 17:38:47.046 (1) simple execute, handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@d3c6a3, maxRows=0,fetchSize=0, flags=17 > 17:38:47.046 (1) FE=> Parse(stmt=null,query="select id, address, citystatezip, combined, degree, email, fax, firstname,groupname, lastname, nfiid, pabsid, practicetype, ssn, telephone, insertby, insertdate, inserttime, updateby, updatedate,updatetime from doctor where id= $1",oids={1043}) > 17:38:47.046 (1) FE=> Bind(stmt=null,portal=null,$1=<0984>) > 17:38:47.046 (1) FE=> Describe(portal=null) > 17:38:47.046 (1) FE=> Execute(portal=null,limit=0) > 17:38:47.046 (1) FE=> Sync And this is the actual refreshRow() query. I assume that this WHERE clause looks correct for your table and that query should be pretty fast? > To me, who knows nothing, the mystery is why 21 repetitions? 21 columns. > I repeated this with another table. The original query had 792 rows. I went to the last row and made a change. This timethere were 408 repetitions. Again, it used the primary key for the $1 parameter shown above. > > So why 408 repetitions this time? 408 columns. Is this a very wide SELECT? I can see that 408 roundtrips would slow things down a lot over a high-latency connection such as over the internet. Perhaps that's the cause of the slowdown you see.. -O
В списке pgsql-jdbc по дате отправления: