Thread: Update on putting WAL on ramdisk/

Some arbitrary data processing job

WAL on single drive: 7.990 rec/s
WAL on 2nd IDE drive: 8.329 rec/s
WAL on tmpfs: 13.172 rec/s

A huge jump in performance but a bit scary having a WAL that can
disappear at any time. I'm gonna workup a rsync script and do some
power-off experiments to see how badly it gets mangled.

This could be good method though when you're dumping and restore an
entire DB. Make a tmpfs mount, restore, shutdown DB and then copy the
WAL back to the HD.

I checked out the SanDisk IDE FlashDrives. They have a write cycle life
of 2 million. I'll explore more expensive solid state drives.

> WAL on single drive: 7.990 rec/s
> WAL on 2nd IDE drive: 8.329 rec/s
> WAL on tmpfs: 13.172 rec/s
>
> A huge jump in performance but a bit scary having a WAL that can
> disappear at any time. I'm gonna workup a rsync script and do some
> power-off experiments to see how badly it gets mangled.

Surely this is just equivalent to disabling fsync? If you put a WAL on a
volatile file system, there's not a whole lot of point in having one at all.

--------------------------------------------------------------------
Russ Garrett                                            russ@last.fm
                                                      http://last.fm

Russell Garrett wrote:
>>WAL on single drive: 7.990 rec/s
>>WAL on 2nd IDE drive: 8.329 rec/s
>>WAL on tmpfs: 13.172 rec/s
>>
>>A huge jump in performance but a bit scary having a WAL that can
>>disappear at any time. I'm gonna workup a rsync script and do some
>>power-off experiments to see how badly it gets mangled.
>
>
> Surely this is just equivalent to disabling fsync? If you put a WAL on a
> volatile file system, there's not a whole lot of point in having one at all.

These tests were all with fsync off.

And no, it's not equivalent to fsync off since the WAL is always written
immediately regardless of fsync setting.