Thinking about this a bit more - if somewhat more blazing performance is
needed, then this could be achieved via losing the RAID card and
spinning disks altogether and buying 1 of the NVME or SATA solid state
products: e.g
- Samsung 960 Pro or Evo 2 TB (approx 1 or 2 GB/s seq scan speeds and
Ah yes - that seems more sensible (but still slower than I would expect
for 5 disks RAID 0). You should be able to get something like 5 *
(single disk speed) i.e about 500MB/s.
Might be worth increasing device read ahead (more than you have
already). Some of these so-called 'smart' RAID cards
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Igor Neyman
Sent: Friday, July 14, 2017 3:13 PM
To: Charles Nadeau
Cc: Jeff Janes ; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Very poor read performance, query independent
Fr
From: Charles Nadeau [mailto:charles.nad...@gmail.com]
Sent: Friday, July 14, 2017 11:35 AM
To: Igor Neyman
Cc: Jeff Janes ; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Very poor read performance, query independent
Igor,
Initially temp_buffer was left to its default value (8MB). Watc
Igor,
Initially temp_buffer was left to its default value (8MB). Watching the
content of the directory that stores the temporary files, I found that I
need at most 21GB of temporary files space. Should I set temp_buffer to
21GB?
Here is the explain you requested with work_mem set to 6GB:
flows=#
Mark,
First I must say that I changed my disks configuration from 4 disks in RAID
10 to 5 disks in RAID 0 because I almost ran out of disk space during the
last ingest of data.
Here is the result test you asked. It was done with a cold cache:
flows=# \timing
Timing is on.
flows=# explain select c
