Re: refreshRow is slow

>> 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