db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Question about FetchDescriptor.materialized_cols
Date Wed, 13 Dec 2006 15:14:02 GMT
Mike Matrigali <mikem_app@sbcglobal.net> 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


Mime
View raw message