11–14 of 14 posts
How does this work while running zfs with LZ4? Has this even been tested on zfs?
Earlier quoted context omitted.
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.
Did you test e.g. LZ4 with a prebuilt dictionary? With a good way to find substrings for the dictionary it might generalize well to other kinds of data.
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.
How does this work while running zfs with LZ4? Has this even been tested on zfs?
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.
Earlier quoted context omitted.
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.
Several reasons. Snapshots, Cloning, Replication. Customized record sizes per database. There are many good reasons to run PG on ZFS and almost everyone does. Except the MySQL/Linux crowd. The rest of have moved on from the pain of the well worn FS's of the distant past.