Re: Quote from comp.object

On 2007-02-28, Aloha Kakuikanu wrote:

>> #2 assumes the database has not been optimized to address this need
>> by physically storing the join rather than physically storing base
>> tables separately (in which case you'd be looking at constant vs.
>> constant).
>
> Is physically storing join practical?

Sometimes it is. Valduriez's join index paper tells you why.

> It requires efficient materialized view update method, and there are
> concurrency concerns, right?

Both true, but 1) materialized view update in full generality is much more complex than dynamically maintaining a two table materialized join or join index, 2) the two table case is far more common than any other, 3) the view update method doesn't even need to be too efficient if the loading mostly consists of reads (i.e. we have an OLAP scenario), and 4) with such loads there is such limited write contention that even full write serialization without any further overhead might pay off (this is what Stonebraker et al.'s C-store relies on).

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2