Re: refreshRow is slow

Поиск
Список
Период
Сортировка
От John T. Dow
Тема Re: refreshRow is slow
Дата
Msg-id 201001160014.o0G0EJWO035231@web2.nidhog.com
обсуждение исходный текст
Ответ на Re: refreshRow is slow  (Oliver Jowett <oliver@opencloud.com>)
Ответы Re: refreshRow is slow  (Oliver Jowett <oliver@opencloud.com>)
Список pgsql-jdbc
>> 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..


While your email was on its way to me, I was looking at the source for refreshrow and came to the conclusion that it's
thenumber of columns. (Actually, 408 is a bit high, but close. Not important.) 

Yes, it is a wide select. Virtually every column in a table is displayable so they all have to be retrieved.

The user who has been complaining (virtually identical code) has a table with only 93 columns, but still that's a lot
ofround trips. 

Certainly that piece of code can be made more efficient. One query ought to be able to return all the primary keys.

I guess something like this won't work, unless "pkey" is reserved: select * from pg_indexes where tablename = 'patinfo'
andindexname = 'patinfo_pkey'. That returns indexdev, which can be parsed to get the columns if needed. 

John


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

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