Thanks for the extended notes. These are very helpful. > "Daniel John Debrunner" wrote:
>https://svn.apache.org/viewcvs.cgi/*checkout*/incubator/derby/code/trunk/ja va/engine/org/apache/derby/iapi/types/package.html > >Generally the Derby engine works upon an array of DVD's that represent a row Are these same DVDs also then used by the log module to create log records? >Interaction with Store What interaction is there with other modules (or functionality) such as log/restore/recovery or the catalog? Are external versions of type descriptors used to create the catalog descriptions of the columns? Used in metadata queries? >DataTypeDescriptor >Note that a DataValueDescriptor is not tied to any DataTypeDescriptor Is this for the same performance reasons given in the DataValueDescriptor section? There you said: 'For example in reading rows from the store a single DVD is used to read a column's value for all the rows processed'. I assume that not tying the value and type descriptors together means that the value descriptors don't need to validate the type when being reused during reads from the store. >Issues >Interfaces or Classes >Code would be smaller and faster if the interfaces were removed Do you have any sense or 'guesstimate' as to what the maximum potential size or speed savings could be? Do you think this may be necessary (as opposed to desireable) for certain environments such as mobile or wireless? Is it conceptually possible to design a 'proof of concept' that might provide at least an estimate of the savings that might be achieved? That is, is there any specific test case that might be useful to see if it is worth exploring further or would the changes be extensive even to perform a limited test?. Obviously the simpler the case the better. >Result Holder Generation >The dynamic creation of result holders (see language section) means that all operators have to check for the result reference being passed in being null, and if so create a new instance of the desired type Could a result holder cache/factory be used effectively for this? Perhaps a separate thread that maintains a cache of new instances of various types. The size of the cache could be configurable by introducing a new property. This would allow the null checks to be removed from the operator code and the operator code would not have to wait synchronously for instance creation. Obviously there would be asynchronous waits since the cache would never be big enough for large numbers of rows.
