Is LZ4 compression of the ZFS L2ARC available in any RELEASE/STABLE?

[Olav Gjerde]

I managed to mess up who I replied to and Matthew replied back with a good
answer which I think didn't reach the mailing list.

I actually have a problem with query performance in one of my databases
related to running PostgreSQL on ZFS. Which is why I'm so interested in
compression for the L2ARC Cache. The problem is random IO read were
creating a report were I aggregate 75000 rows takes 30 minutes!!! The table
that I query has 400 million rows though.
The dataset easily fit in memory, so if I run the same query again it takes
less than a second.

I'm going to test UFS with my dataset, it may be a lot faster as you said.
Currently I've only tested ZFS with gzip, lz4 and no compression. Gzip and
no compression has about the same performance and LZ4 is about 20%
faster(for both read and write). LZ4 has a compressratio about 2.5 and
gzip9 has a compressratio that is about 4.5

Steven Hartland, thank you for your suggestion. I will try the 10-STABLE
then instead of a RELEASE.


On Tue, Mar 4, 2014 at 2:25 PM, Matthew Seaman <matthew at freebsd.org> wrote:

> On 03/04/14 12:17, Olav Gjerde wrote:
> > This is really great, I wonder how well it plays together with PostgreSQL
> > and a SSD.
>
> You probably *don't* want to turn on any sort of compression for a
> Postgresql cluster's data area (ie. /usr/local/pgsql) -- and there are a
> bunch of other tuning things to make ZFS and Pg play well together, like
> adjusting the ZFS block size.  The sort of small random IOs that RDBMSes
> do are hard work for any filesystem, but particularly difficult for ZFS
> due to the copy-on-write semantics it uses.  It's a lot easier to get
> good performance on a UFS partition.
>
> On the other hand, ZFS has recently grown TRIM support, which makes it a
> much happier prospect on SSDs.
>
>         Cheers,
>
>         Matthew
>
>
>
>


-- 
Olav Grønås Gjerde