Re: 9.0 Driver

On Tue, 10 Aug 2010 13:56:27 -0400 (EDT), Kris Jurka wrote:

>
>
>On Sun, 8 Aug 2010, John T. Dow wrote:
>
>> There is, I believe, a problem with the JDBC driver in that it gives
>> very poor performance doing a refreshRow. The problem is that the driver
>> queries the server for every column in the resultset.
>>
>> I implemented a quick and dirty fix by modifying the driver to (on
>> demand) use the labels returned in the resultset.
>>
>> This solution of course will fail if the original query used an alias
>> for a column. Other than that, it seems to be a good solution.
>>
>> Apparently I am the only one who uses refreshrow, because I reported the
>> fact that it was slow in January (and there was a little discussion) but
>> when in April I reported my crude solution there was no discussion.
>
>I think it's a combination of factors, few people use refreshRow and fewer
>people use it on results with hundreds of columns. Yes, it is slow, but
>it isn't abysmal and it's only slow for the first refreshRow execution
>on the ResultSet, so subsequent refreshes are fast. As you've stated, the
>solution you've implemented is inadequate for the general case, so I'm not
>sure what further discussion there should be about it. Is there something
>in particular you'd like feedback on?
>
>So yes, it's a known issue, but not a high priority one.
>
>Kris Jurka
>
>

I see that once a field gets its name, it remembers it. You're right about that.

I am not looking for any feedback on my quick and dirty solution, although it seemed that if others were experiencing the problem they might be interested to know that there is a solution of sorts at hand. Didn't happen. I must be alone.

All I know is a client complained that it was taking 20 seconds for their remote warehouse staff to update the database. Made me look bad after I'd sold them on PG. (I timed it - it wasn't always that bad, but after I implemented my fix and tested it several times, it dropped from 15 seconds to 3 seconds to do a refreshRow.)

I should think the code could get all the attname, attnum pairs for a given attrelid with one round trip and cache the results. Is there some good reason not to do so?

John