Re: Why HDD performance is better than SSD in this case

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Neto pr <netopr9(at)gmail(dot)com>
Cc: Fabio Pardi <f(dot)pardi(at)portavita(dot)eu>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Why HDD performance is better than SSD in this case
Date: 2018-07-23 00:07:16
Message-ID: c8c36fe8-e1a8-694a-70db-72f32bcda781@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi Neto,

In a great piece of timing my new experimental SSD arrived (WD Black 500
G 3D NAND MVME) [1]. Doing some runs of query 9:

- default config: 7 minutes

- work_mem=1G, max_parallel_workers_per_gather=4: 3-4 minutes

Increasing either of these much more got me OOM errors (16 G of ram).
Anyway, enjoy your benchmarking!

Cheers
Mark

[1] Yeah - I know this is a 'do not use me in production' type of SSD.
It is however fine for prototyping and DSS scenario run type use.

On 20/07/18 12:52, Neto pr wrote:
>
> Mark,
> This query 9 is very hard, see my results for other queries (attached
> - test with secondary index and without secondary index - only primary
> keys), the SSD always wins in performance.
> Only for this query that he was the loser, so I put this topic in the list.
>
> Today I will not be able to check your test information in more
> detail, but I will return with more information soon.
>
> Best Regards
> Neto
>
>
>
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas Güttler 2018-07-23 11:18:02 Profile what the production server is doing
Previous Message Andres Freund 2018-07-20 16:45:10 Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)