db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2336) Enable collation based ordering for CHAR data type.
Date Wed, 07 Mar 2007 01:43:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478665
] 

Mike Matrigali commented on DERBY-2336:
---------------------------------------

Currently both heap and btree has the 1st row on page 0 as a free format "metadata" row. 
There will need to be upgrade support but it can be handled "on-the-fly" depending on what
new info you want to add (ie. basically it is easy if  there is a workable default the missing
data for old tables - so for instance in this discussion existing tables would somehow be
set with the UCS_BASIC collation).  
By on the fly I mean automatically when the table is accessed rather than as part of the boot
upgrade process.

There is actually some dead code in java/engine/org/apache/derby/impl/store/access/btree/index/B2I.java
:
(writeExternal_v36 and readExternal_v36)  showing how we handled a pre-derby upgrade  to this
metadata when we added
the storing of ascending/descending information. 
 I'll look at getting rid of the dead code.

The cost is disk space in page 0 which is the root page and thus a level is added to the btree
sooner  
The limitation is that all the info in the metadata has to fit on the page.   So for instance
I would not like to add a possibly long 
string for every column.  

Since the info we are setting is really one piece of info per db, setting it once per table
or worse once per column seems overkill.  We
may want to do that in the future, and we have the infrastructure to do it when we need to
- but should we do it now?

So we could do this but  I still wonder about getting this info and packaging it up for every
template call to the datatype.  Note that these
template creations don't just happen for recovery.  They happen during other normal forward
processing operations.  Some examples
are that we need a scratch template to do a search on a btree, we need some scratch templates
to do btree splits, we create some
templates for bulk operations from heap and btree (like hash scan result sets).  

> Enable collation based ordering for CHAR data type.
> ---------------------------------------------------
>
>                 Key: DERBY-2336
>                 URL: https://issues.apache.org/jira/browse/DERBY-2336
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>         Attachments: DERBY_LocalFinder_CodeCleanup_diff_V01.txt, DERBY_LocalFinder_CodeCleanup_stat_V01.txt
>
>
> I am breaking down the Parent task DERBY-1478 (Add built in language based ordering and
like processing to Derby) into multiple sub tasks. One of them is to concentrate on enabling
the collation based ordering on (hopefully the simplest of all the character data types) CHAR
data type. This task in itself might need subtasks if it is later found that it can be subdivided
into multiple smaller steps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message