afiskon

More links (in Russian): http://rsdn.org/forum/life/6717583 + https://xakep.ru/2017/03/07/kris-kasperski-rip/

Wiki page about Kris https://en.wikipedia.org/wiki/Kris_Kaspersky

Done https://news.ycombinator.com/item?id=12838767

@brudgers suggested to re-send this link as "Show HN" https://news.ycombinator.com/item?id=12834893 Sorry for a copy, unfortunately I'm unable to edit or delete an original submission.

Thanks for advice. I'll try it!

Very interesting. For some reason I always thought that no one runs PostgreSQL on ZFS. If it's not a secret, what company uses PostgreSQL on FreeBSD like this?

Frankly I don't remember, it was more then half a year ago.

LZ4 is a LZ77 family algorithm which means its dictionary is a "shifting window". I don't believe such kind of dictionary will fit in this case.

No, I didn't test it on ZFS. Sorry for asking, but is there any reason to run DBMS (which I would like to remind has a build-in compression) on ZFS which itself is a small DBMS? Sounds like too much unnecessary overhead to me.

Thank you for an interesting idea! I can't promise I will implement it myself any time soon, however. You know the saying - pull requests are welcome :)

I'm afraid Snappy will not help, at least a lot. PostgreSQL already has a build-in compression (PGLZ). I tested various different algorithms before this shared-dictionary-idea - lz4, bzip and others. Some compress a bit better, other a bit faster, but in general result is almost the same.

Frankly I don't remember all details since I did this benchmark in February. IIRC its "ZSON + PGLZ" vs "JSONB + PGLZ".

Please note that everything depends very much on your data. PostgreSQL is smart about what to compress and what not. In general it could be all combinations of "ZSON +/- PGLZ" vs "JSONB +/- PGLZ".

Don't believe any benchmark I or anyone else did. Re-check everything on your data, configuration, hardware, workload, etc.