On Sat, Jul 7, 2018 at 4:01 PM, Andres Freund wrote:
> FWIW, here's a rebased version of this patch. Could probably be polished
> further. One might argue that we should do a bit more wide ranging
> changes, to convert scanint8 and pg_atoi to be also unified. But it
> might also just be worthwhile
>Model: 850 Evo 500 GB SATA III 6Gb/s -
please check the SSD *"DRIVE HEALTH STATUS"* and the* "S.M.A.R.T values of
specified disk" *
for example - with the "smartctl" tool ( https://www.smartmontools.org/
) ( -x "Show all information for device" )
Expected output with "Samsung SSD 850 EVO
On Wed, 18 Jul 2018 09:46:32 +0200, Fabio Pardi
wrote:
RAID 0 to store production data should never be used. Never a good
idea, in my opinion.
RAID 0 by itself should never be used. Combined with other RAID
levels, it can boost performance without sacrificing reliability.
https://en.wiki
Ok, so you are using 1 instance and tablespaces. Also I see you are
restarting the instance between HDD and SSD tests, so all good there.
The point I made about having the OS on the SSD's means that if these
tests make your system swap, and your swap device is on the SSDs (which
is probably is
Le 18/07/2018 à 03:16, Neto pr a écrit :
2018-07-17 22:13 GMT-03:00 Neto pr :
2018-07-17 20:04 GMT-03:00 Mark Kirkwood :
Ok, so dropping the cache is good.
How are you ensuring that you have one test setup on the HDDs and one on the
SSDs? i.e do you have 2 postgres instances? or are you using
Hi Neto,
RAID 0 to store production data should never be used. Never a good idea, in my
opinion.
Simple reason is that when you lose one disk, you lose everything.
If your goal is to bench the disk, go for single disk.
If you want to be closer to a production setup, go for RAID 10, or pick a R
