Re: WORM and Read Only Tables (v0.1)

Simon,

> Use Case: VLDB with tons of (now) read only data, some not. Data needs
> to be accessible, but data itself is rarely touched, allowing storage
> costs to be minimised via a "storage hierarchy" of progressively cheaper
> storage.

There's actually 2 cases to optimize for:
1) write-once-read-many (WORM)
2) write-once-read-seldom (WORS)

The 2nd case is becoming extremely popular due to the presence of 
government-mandated records databases.  For example, I'm currently working on 
one call completion records database which will hold 75TB of data, of which 
we expect less than 1% to *ever* be queried.

One of the other things I'd like to note is that for WORM, conventional 
storage is never going to approach column-store DBs for general performance.  
So, should we be working on incremental improvements like the ones you 
propose, or should we be working on integrating a c-store into PostgreSQL on 
a per-table basis?


-- 
Josh "the Fuzzy" Berkus
San Francisco