Re: extra rowcopy in ResultSet allways needed ?.

hello,

I would be happy if someone could explain something i dont understand in
the current code.

Is the extra rowcopy allways needed to be done, for example in boolean
next() method in resultset ?

Is the copy not only needed in some detectable special case ?.

thanks
gustav

On Sat, 16 Feb 2008, Gustav Trede wrote:

> Is the extra rowcopy allways needed to be done, for example in boolean
> next() method in resultset ?
>
> Is the copy not only needed in some detectable special case ?.
>

The rowBuffer copy is only needed for updateable ResultSets, so we could
probably wrap all those calls with isUpdateable() { }. Are you seein a
significant performance impact from those calls or are you just curious?

Kris Jurka

Gustav Trede wrote:
> Kris Jurka skrev:
>> The rowBuffer copy is only needed for updateable ResultSets, so we
>> could probably wrap all those calls with isUpdateable() { }. Are you
>> seein a significant performance impact from those calls or are you
>> just curious?
>>
>
> its good news that its avoidable.
> I buffer roughly 2Gbyte of data by jdbc in RAM.
> im using several threads to max the speed and im currently cpu bound for
> performance.
> its importent for me to keep the init time as low as possible, since it
> delays failover response in my setup.
> (long time outs on client IO keeps client in an ok state though.)
>
> I have a general interests in performance despite that im using
> webservices for clients =),
> and tend to look around in code on my sparetime, and i sometimes find
> things.
> Whenever the things are not risky to implement, its often to be
> considered free as in beer.
> Its only if there is noticable complexity, that the performance boost
> must be proven to be very substantial inorder
> to motivate risky code changes imo.
>
> I would be happy if its possible to check for isUpdatable in the
> official codebase,
> its a mess for me to keep local patches synced with CVS.
>
> I dont have any hard numbers atm.
> If its needed, i can try to provide it next week or so ?
>

No I don't need the numbers, I was just curious if you had them handy.
Also I was initially looking at the full cost of isUpdateable and the
idea that for a small ResultSet it would be faster to just do the copy
rather than doing the parsing and stuff to see if a ResultSet was
updateable. Re-reading that now, we don't really want to call
isUpdateable, but probably just wrap things in "if (resultsetconcurrency
== ResultSet.CONCUR_UPDATABLE) { } ". That'll be a simple quick check
that should always be a win.

So are you planning on coding this up, or just throwing it out as a
suggestion?

Kris Jurka

Gustav Trede wrote:
>
> I will do it for all methods that is not update methods.
> doing it in one method and then call it.
>
> i just attach the new AbstractJdbc2ResultSet.java in an email or ?
>

A patch would be better. If you've got cvs checkout, the "cvs diff -c"
is what we'd like to see.

Also, please keep replies on the list so other people can read/comment
on your emails.

Kris Jurka

here is diff from current cvs.
>
>>
>> I will do it for all methods that is not update methods.
>> doing it in one method and then call it.
>>
>> i just attach the new AbstractJdbc2ResultSet.java in an email or ?
>>
>
> A patch would be better. If you've got cvs checkout, the "cvs diff
> -c" is what we'd like to see.
>
> Also, please keep replies on the list so other people can read/comment
> on your emails.
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 2880 (20080215) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

On Wed, 20 Feb 2008, Gustav Trede wrote:

>
> here is diff from current cvs.

Patch applied, thanks. The one minor change I made was to set rowBuffer =
null instead of rowBuffer = this_row in the non-updatable case to catch
any potential issues where the rowBuffer was being used improperly.

Kris Jurka