11–20 of 59 posts
What I'd really like is a multiprocess safe embeddable database written in pure Go. So a database which is safe to read and write from separate processes. Unfortunately I don't think this one is multiprocess safe.
What is the use case? Why is it important that "All keys, values are backed by blake 256 bit checksum"?
Nice! I implemented pretty much the same trade off set in an authenticated storage system. single writer, radix merkle tree, persistent storage, hashed keys, proofs. I guess it is a local maxima within that trade off space. I like how the time travelling/history is always touted as a feature (which it is), but it really just means the garbage collector/pruning part of the transaction engine is missing. Postgres and o…
> I like how the time travelling/history is always touted as a feature (which it is), but it really just means the garbage collector/pruning part of the transaction engine is missing. Postgres and other mvcc systems could all be doing this, but they don't. Postgres actually did tout it as a feature in "THE IMPLEMENTATION OF POSTGRES" by Michael Stonebraker, Lawrence A. Rowe and Michael Hirohama[1] search for "time tr…
What is the use case? Why is it important that "All keys, values are backed by blake 256 bit checksum"?
ZFS stores the checksums of files to prevent bit rotting. Since they are comparing their database to ZFS, I guess it stores the checksums for the same reason. If bit rotting occurs, you don't need to discard the entire database, just the affected entry. If the entry was already there for some time, you might even be able to restore it from a backup.
Earlier quoted context omitted.
> I like how the time travelling/history is always touted as a feature (which it is), but it really just means the garbage collector/pruning part of the transaction engine is missing. Postgres and other mvcc systems could all be doing this, but they don't. Postgres actually did tout it as a feature in "THE IMPLEMENTATION OF POSTGRES" by Michael Stonebraker, Lawrence A. Rowe and Michael Hirohama[1] search for "time tr…
Is this still possible with Postgres?
PostgreSQL still does copy-on-write so the old versions of the row exist and are present in storage. However now there is an autovacuum process going over the records regularly marking those no longer seen by any transactions as re-usable so eventually the old records would get overwritten.
You can get at the older versions of the rows directly on disk or perhaps it would be possible to get the db to return such older versions of the rows. It seems that by default even trying to get at them with `ctid` is not possible so that may require hacking PostgreSQL itself or using some extension which seem to actually exist[1].
[1] - https://github.com/omniti-labs/pgtreats/tree/master/contrib/...
Also,
>Superfast proof generation time of around 1000 proofs per second per core.
Does this limit in any way things like read/write perfomance or usability in general?
What I'd really like is a multiprocess safe embeddable database written in pure Go. So a database which is safe to read and write from separate processes. Unfortunately I don't think this one is multiprocess safe.