From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: intel s3500 -- hot stuff |
Date: | 2014-12-09 20:43:37 |
Message-ID: | 20141209204337.GC24488@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Mon, Dec 8, 2014 at 03:40:43PM -0600, Merlin Moncure wrote:
> >> Did not see consistent measurable gains > 256
> >> effective_io_concurrency. Interesting that at setting of '2' (the
> >> lowest possible setting with the feature actually working) is
> >> pessimal.
> >
> > Very interesting. When we added a per-tablespace random_page_cost,
> > there was a suggestion that we might want to add per-tablespace
> > effective_io_concurrency someday:
>
> What I'd really like to see is to have effective_io_concurrency work
> on other types of scans. It's clearly a barn burner on fast storage
> and perhaps the default should be something other than '1'. Spinning
> storage is clearly dead and ssd seem to really benefit from the posix
> readhead api.
Well, the real question is knowing which blocks to request before
actually needing them. With a bitmap scan, that is easy --- I am
unclear how to do it for other scans. We already have kernel read-ahead
for sequential scans, and any index scan that hits multiple rows will
probably already be using a bitmap heap scan.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-12-09 21:10:02 | Re: moving from contrib to bin |
Previous Message | Robert Haas | 2014-12-09 20:35:42 | Re: advance local xmin more aggressively |
From | Date | Subject | |
---|---|---|---|
Next Message | Strahinja Kustudić | 2014-12-09 23:28:47 | 8xIntel S3500 SSD in RAID10 on Dell H710p |
Previous Message | Claudio Freire | 2014-12-09 18:55:47 | Re: Hardware Requirements |