Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XyRdH-0000zB-M9 for pgsql-performance@arkaria.postgresql.org; Tue, 09 Dec 2014 20:43:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XyRdG-0007fi-JT for pgsql-performance@arkaria.postgresql.org; Tue, 09 Dec 2014 20:43:42 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XyRdF-0007fc-Pu for pgsql-performance@postgresql.org; Tue, 09 Dec 2014 20:43:41 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XyRdC-0007e4-Lb for pgsql-performance@postgresql.org; Tue, 09 Dec 2014 20:43:40 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1XyRdB-0001IB-VG; Tue, 09 Dec 2014 15:43:37 -0500 Date: Tue, 9 Dec 2014 15:43:37 -0500 From: Bruce Momjian To: Merlin Moncure Cc: postgres performance list Subject: Re: intel s3500 -- hot stuff Message-ID: <20141209204337.GC24488@momjian.us> References: <20141206130828.GA1314@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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 http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance