Chris,
> Hmm. Are you trying to do something sort of like CStore?
>
> http://db.csail.mit.edu/projects/cstore/
>
> That seems to have some relevant ideas...
I think "something like" is a good way to put it. As you know Cstore was a
prototype for Vertica and these are in the same class as SybaseIQ and
SandDB.
The huge drawback of the pure column approach is update/insert while query
is difficult if not impossible. I think there are hybrid approaches that
yield most, if not all of the benefits of the column store approach without
the disadvantages.
For instance, a bitmap index with index only access in a row-store may
outperform the column store on queries. Note the "index only access" part.
The next advantage of a column store is deep compression, preserved through
the executor access path - we can do this with selective vertical
partitioning using a page-segmented WAH compression similar to what we did
with bitmap index. Lastly, vectorization of the operators in the executor
can be implemented with vertical partitioning and an access path that does
projection before feeding the columns into the executor - this can be done
in Postgres with a cache-bypass method. Some of this requires working out
answers to the visibility challenges inherent to MVCC, but it's all possible
IMO.
So - under the guise of "TOASTing smaller things", it seems relevant to
think about vertical partitioning, perhaps making use of what's already in
Postgres as baby steps toward more advanced features.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
