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 time there 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 the number 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 of round 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' and indexname = 'patinfo_pkey'. That returns indexdev, which can be parsed to get the columns if needed.

John