db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: [PATCH] DERBY-302 Insert on clob of 500k of data takes long time
Date Sat, 11 Jun 2005 00:59:30 GMT
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.



Mime
View raw message