Mike Matrigali <[EMAIL PROTECTED]> writes: > as with most "RESOLVES" and "TODO" still in the code, it has been > a long time since anything has happened on them.
I'm not unfamiliar with that phenomenon :) Thank you very much for answering my question and starting the new thread. I need some time to digest what you write below (and in the new thread). > FetchDescriptor came about from a profiling/performance pass on the > code. An array was chosen so that no routine and/or math would > be needed to set/clear the info. Int's were chosen as likely to be > fasted data structure across all OS/JVM. Most of this work was done > to optimize various scans (ie. scans of all cols all qualifying, scans > of all cols 1% qualify, scans of some cols all qualifying, scans of some > cols 1% qualifying). At the time this was the > fastest data structure, faster than bits - and especially faster > than bits if number of bits might be large (ie. bigger than 8 or 32 - > so that some array reference was necessary). > > I haven't thought about what it would mean to cache the offset, one > would need to have some sort of validation of the value after the > latch were released. The > case where one needs to find the column again after qualifying (where > this code is), is a subsequent update of a column after this row > is returned to the caller in a scan as a qualifying row. Note that > the "normal" qualifying path for many apps is find a by key in index > and then update non-key field of heap - in that case this code is > not used. -- dt
