Re: refreshRow is slow

Поиск
Список
Период
Сортировка
От John T. Dow
Тема Re: refreshRow is slow
Дата
Msg-id 201001152307.o0FN7Aw2027525@web2.nidhog.com
обсуждение исходный текст
Ответ на refreshRow is slow  ("John T. Dow" <john@johntdow.com>)
Ответы Re: refreshRow is slow  (Oliver Jowett <oliver@opencloud.com>)
Список pgsql-jdbc
I observe the following in the jdbc log.

There's the original read only query, with 722 rows. The actual query was "SELECT * FROM doctor WHERE 1 = 1". Yes, I
knowit could just be "SELECT * FROM doctor" but the query is generated based on user input, and that's my version of a
nullwhere clause. 

After the first row of the result set was displayed, I changed a field and updated the table. The log shows the query
"forupdate" and later a commit. 

Following that, where my program would do the refreshRow on the original resultset, I find a 21 instances of this block
(somelines 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>)
17:25:50.812 (1)  FE=> Describe(portal=null)
17:25:50.812 (1)  FE=> Execute(portal=null,limit=0)
17:25:50.812 (1)  FE=> Sync
17:25:50.812 (1)  <=BE ParseComplete [null]
17:25:50.812 (1)  <=BE BindComplete [null]
17:25:50.812 (1)  <=BE RowDescription(1)
17:25:50.812 (1)  <=BE DataRow
17:25:50.812 (1)  <=BE CommandStatus(SELECT)
17:25:50.812 (1)  <=BE ReadyForQuery(I)

The only difference between the 21 blocks is that the $2 parameter goes 1, 2, 3, 4, ... 21

After the 21st block comes this, and that ends the log.

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
17:38:47.046 (1)  <=BE ParseComplete [null]
17:38:47.046 (1)  <=BE BindComplete [null]
17:38:47.046 (1)  <=BE RowDescription(21)
17:38:47.046 (1)  <=BE DataRow
17:38:47.046 (1)  <=BE CommandStatus(SELECT)
17:38:47.046 (1)  <=BE ReadyForQuery(I)
17:38:47.046 (1) done updates
17:38:49.765 (1)  FE=> Terminate

The value 0984 is the primary key value for the row I changed.  I repeated this with the same original resultset, but
movedto the 25th row before making a change. Again it did 21 instances of this block (the primary key value was of
coursedifferent). 

To me, who knows nothing, the mystery is why 21 repetitions?

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?

John


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Maciek Sakrejda
Дата:
Сообщение: Re: COPY using Hibernate
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: refreshRow is slow