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.
