db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2537) implement pushing collation info to store, storing collation info in store metadata, and creating templates based on store metadata
Date Fri, 25 May 2007 10:39:16 GMT

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

Knut Anders Hatlen commented on DERBY-2537:

Are there any plans to investigate what caused the performance regression Olav reported in

> implement pushing collation info to store, storing collation info in store metadata,
and creating templates based on store metadata
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2537
>                 URL: https://issues.apache.org/jira/browse/DERBY-2537
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL, Store
>            Reporter: Mike Matrigali
>         Assigned To: Mike Matrigali
>             Fix For:
>         Attachments: derby-2537_3.diff, derby2537_1.diff, derby2537_2.diff
> Implement subtasks associated with pushing and using collation info in store.
> As was discussed on list the aproach will be:
> o store collation info gets passed into createConglomerate() using an enhanced version
of the exising CollumnOrdering interface
> o store collation info will also have to get passed into interface that adds a column
to a heap
> o collation info will be added to the store metadata so that correct collation datatypes
can be created internal to store where there
>     may no access to system catalogs (for instance at  database recovery time).   A new
heap and btree metadata version will be
>     added which will included a "sparse" on disk format which will describe those columns
that have a collation id that is different
>     than the default.  
> o soft upgrade will be handled by insuring old format is readable by existing code and
automatically creates current version of in memory structures by
>     assuming all old format conglomerates have default collation info.  Soft upgrade
will never create new format heap or btree metadata.
> o hard upgrade will  write new format conglomerate metadata for conglomerates created
after the upgrade, no work  will be done at upgrade time.  
>     Note the  proposed implementation of collation feature in 10.3 will only allow new
dbs to set alternate collation, so in 10.3 hard upgrade is not 
>     actually necessary but  provides a consistent approach to internal store structures.
 It also will allow  for a future where more collation control
>     is allowed in dbs.
> o store needs to create templates sometimes, to do this with correct collation info some
of the Monitor functionality to create templates will be
>     moved from monitor into datatype factory and enhanced to take collaiton id info where
it currently only takes format ids.

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

View raw message