Alvaro, I have previously posted ZFS numbers for SmartOS and FreeBSD to this thread, although not with the exact same benchmark runs that Tomas did.
I think the main purpose of running the benchmarks is to demonstrate that there is no significant performance regression with wal recycling disabled on a COW filesystem such as ZFS (which might just be intuitive for a COW filesystem). I've tried to be sure it is clear in the doc change with this patch that this tunable is only applicable to COW filesystems. I do not think the benchmarks will be able to recreate the problematic performance state that was originally described in Dave's email thread here: https://www.postgresql.org/message-id/flat/CACukRjO7DJvub8e2AijOayj8BfKK3XXBTwu3KKARiTr67M3E3w%40mail.gmail.com#cacukrjo7djvub8e2aijoayj8bfkk3xxbtwu3kkaritr67m3...@mail.gmail.com Thanks, Jerry On Wed, Aug 22, 2018 at 8:41 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2018-Aug-22, Andres Freund wrote: > > > On 2018-08-22 11:06:17 -0300, Alvaro Herrera wrote: > > > > I suppose that the use case that was initially proposed (ZFS) has not > > > yet been tested so we shouldn't reject this patch immediately, but > > > perhaps what Joyent people should be doing now is running Tomas' test > > > script on ZFS and see what the results look like. > > > > IDK, I would see it less negatively. Yes, we should put a BIG FAT > > warning to never use this on non COW filesystems. And IMO ZFS (and also > > btrfs) sucks badly here, even though they really shouldn't. But given > > the positive impact for zfs & btrfs, and the low code complexity, I > > think it's not insane to provide this tunable. > > Yeah, but let's see some ZFS numbers first :-) > > -- > Álvaro Herrera https://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
