I've got a pretty good idea where you might have read this.
The actual implementation and with it the performance characteristics are not like you describe it.
There is no row-wise decompression required for update or delete.
The data does not need to get materialized.
Instead also the delta store (just stick with the one-level delta store for now - it's anyhow what you would see 99% of all cases) is also using pointers to a dictionary.
This dictionary however is not organized the same way as in the main store (it's not a sorted list and the dictionary entries are not compressed).
However, the same values in main and delta store map to the same dictionary IDs.
So, in order to update a record, it's required to:
- retrieve the original dictionary IDs from main or delta store (wherever the most current version is stored)
- set the validity indicator to "expired"
- insert the changed record into the delta store
- update this records validity indicator
This can be done in parallel (multiple columns at the same time).
Compared to this, how efficient do you think are in-place updates in a row store DBMS?
Combine this with MVCC and you will end up with either bad write-performance or the constant need to reorganize your data structures, which opens a completely new can of worms.
And, if we follow your idea of the column-wise update, that only considers the touched columns, how should tuple-reconstruction work then? BTW: reading the data is still a lot more prevalent than writing it, so the emphasis on optimization should be made there.
I'm not saying all is great about the column store as we have it, but it's a lot easier to point out the possible issues than to come up with a much better way to handle it.
Based on your description, the system might be too small to cope with this size of updates. So breaking it down either via batches or via partitioning are two options here.
- Lars