db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [PATCH] DERBY-302 Insert on clob of 500k of data takes long time
Date Mon, 13 Jun 2005 15:19:43 GMT
I have committed this patch with svn 190415

Sunitha Kambhampati wrote:
> Thanks Mike for your feedback.
> Mike Matrigali wrote:
>> all the code looks right to me, but I have some questions that may be
>> nit performance issues.
>> 1) should most of the new routines you added be "final" - except for the
>> SQLChar one which gets overridden.
>> 2) There are a lot of numbers rather than names for numbers, I realize 
>> you are following what was there.  but just a little hard to read and
>> if any of the numbers relate to each other it is hard to tell.
>> 3) and sort of part of 2 - should the grow by number relate to the 
>> number which decides when to return a buffer back to the VM rather than
>> cache the buffer in the datatype.  This code is around because on a
>> select of 1 million rows derby will only allocate one SQLChar per CHAR
>> collumn - not 1 million.  I think the case I am wondering about is a
>> VARCHAR bigger than 64 bytes but less than 4k.  Does grow by 4k mean
>> the varchar buffer will start at 64 and then go to 64+4k - if so seems
>> like we should cache the buffer at 64+4k not 4k.
> For 3, We will not hit this case.  The varchar will growby 4k , and not 
> 64+4k.    And the size that decides when to return buffer back to vm is 
> 4k.   ( code is in getString())
> so
> - growby for char is 64 bytes
> - growby for varchar and clob is 4k
> but since the size that decides when to return a buffer back to the vm 
> is 4k, so not directly related to the growby number for char, but is the 
> same for varchar and clob. 
> I have taken care of #1 and #2 comments  and have attached the patch on 
> jira.
> Thanks,
> Sunitha.

View raw message