We saved millions in SSD costs by upgrading our filesystem

Re:We saved millions in SSD costs by upgrading our filesystem by nwmcsween on Tuesday November 09, 2021 @02:30PM (#29166288)

OK a one thing that stands out here and please correct me if I'm wrong:

> ... multi-petabyte cluster of Postgres instances... blocksize relatively high at 64 kb ...

The dataset should be the Postgresql "page size" which IIRC is 8KB, the reasoning for this is RMW cycles will read 64kb modify 8KB and write out the full 64KB amplifying writes 8 fold.

Also IIRC Postgresql will automatically use TOAST when needed?

[ Parent | on HN ]

Re:We saved millions in SSD costs by upgrading our filesystem by jhk727 on Tuesday November 09, 2021 @02:53PM (#29166608)

Good callout - we use a higher blocksize than Postgres page size because it gives us a much higher compression ratio, at the cost of some read/write amplification.

And yes - Postgres will automatically TOAST oversized tuples and compress the relevant data (if you configure it to do so). This is much lower impact for us than filesystem level compression, as it doesn't affect the main relation heap space (or any indexes).

[ Parent | on HN ]

Re:We saved millions in SSD costs by upgrading our filesystem by nwmcsween on Tuesday November 09, 2021 @03:57PM (#29167374)

What about: https://people.freebsd.org/~seanc/postgresql/scale15x-2017-p...

16k record size 2x amplification and still (?) allows compression w/ lz4

[ Parent | on HN ]

Re:We saved millions in SSD costs by upgrading our filesystem by jhk727 on Tuesday November 09, 2021 @04:19PM (#29167625)

We tested this extensively a few years back. We saw a compression ratio of ~1.9 with 8k recordsize/lz4, ~2.7 with 16k/lz4, and now ~5.5 with 64k/zstd.

[ Parent | on HN ]

Re:We saved millions in SSD costs by upgrading our filesystem by nwmcsween on Tuesday November 09, 2021 @03:31PM (#29167060)

There has to be something better than a potential 8 fold write performance reduction wrt compression

[ Parent | on HN ]