Pluggable storage

[kiwicopple]

Maybe you can research a bit pluggable table storage interface in PostgreSQL. It is possible either to implement your storage, which works fine with CRDT, or try to find some storage implementation, which works fine with such usage pattern (like, https://wiki.postgresql.org/wiki/Zheap )

Idea from Hixon10

[akorotkov]

Good idea. Writing the whole new pluggable storage just for CRDT might be an overkill. But adding proper CRDT support to an existing one should be good. My proposal is to add CRDT to OrioleDB.

I think we should achieve the following goals.

1. Allow multiple in-progress transaction to update a the single CRDT value simultaneously.
2. Amount of WAL should be proportional to size of updates, not size of documents.

Regarding the first goal, OrioleDB already utilizes undo log. So, each row have a chain of modification undo records. We already handle a situation when there are multiple in-progress undo records for the same row (this is how we handle row-level locks). All we need to do is to define a new type of undo records for CRDT, and we would be able to allow multiple transactions to simultaneously update a singe CRDT value.

Regarding the second goal, OrioleDB utilizes row-level WAL. In fact, the whole requirement for WAL records is idempotency (it shouldn't cause a trouble when the same record is applied twice). Therefore, we can define new WAL records for CRDT, which carry only modification, not the whole document.

To achieve this goals for large CRDT values, we also need to work on TOAST in OrioleDB. We would need to be able to update only certain TOAST chunks in order to keep changes of individual UPDATE small. For CRDT, that means we need to design TOAST so that individual chunks are meaningful even without the full document. So, if you have small update for CRDT value, database can navigate over document and update the relevant chunk without touching all the chunks.