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: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 20:03:13 GMT

Rick Hillegas wrote:
>> This is where I get confused.  Are multiple collations required in a 
>> single database?  With plans for DERBY-1478 it isn't.  With new 
>> collations it isn't.
>> With collation per-schema it is, but should we pay overhead now for a
>> possible future, as long as we have a design that supports an upgrade
>> path to it?
>> I am not seeing the value in the argument for storing it once per
>> table vs. once per database today.
> Hi Mike,
> Can you expand on this? What is the overhead we're avoiding?
> Thanks,
> -Rick

Pushing an extra argument on every object creation for each member of a 
template. Interpreting the extra argument in the object creation call.
Storage space in the conglomerate.  Code to read/write the extra 
metadata.  The templates in the worst case are created once for each 
conglomerate/index accessed in each sql statement.  In best case the 
templates are reused across executions of same prepared statement.

I admit all this may be small, and if we NEED it then I have no problem
it being added.  I just have a problem if there is no need.  I have been
burnt in the past adding stuff that I thought might be useful in the 
future, so now I tend to lean toward implementing what we need today, 
while making sure there is a reasonable upgrade path in the future.  If 
I thought today's code was making it harder for a future path that would 
be a different case.  For
example what if whatever way we decide to store the value of the 
collation today, turns out not to work for future expansions of the 
collation - and we could have gotten away with storing it once per
db vs once per table.  Now we have a much bigger upgrade issue.

The system catalog implication may make this all a moot discussion, it 
may be the reason we need per-schema collations.  Mamta's original
design handled system catalog vs non system catalog with format id's so
there was no need for per conglomerate collations.  I didn't realize 
until my last message that Dan's proposal would need multiple collations 
in a single db in 10.3.
>>> Thanks,
>>> Dan.

View raw message