Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYh7v-0002s1-GB for pgsql-performance@arkaria.postgresql.org; Tue, 22 Oct 2013 18:56:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VYh7u-0007zF-Uk for pgsql-performance@arkaria.postgresql.org; Tue, 22 Oct 2013 18:56:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYh7t-0007z4-RS for pgsql-performance@postgresql.org; Tue, 22 Oct 2013 18:56:21 +0000 Received: from smtp.01.com ([199.36.142.181]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYh7p-0006MV-Qp for pgsql-performance@postgresql.org; Tue, 22 Oct 2013 18:56:21 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A812C294081 for ; Tue, 22 Oct 2013 13:56:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J475nBPTkDiH for ; Tue, 22 Oct 2013 13:56:16 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 85F1E29409D for ; Tue, 22 Oct 2013 13:56:16 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 70E79294082 for ; Tue, 22 Oct 2013 13:56:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LRKb6XqsRiIL for ; Tue, 22 Oct 2013 13:56:16 -0500 (CDT) Received: from [172.47.23.102] (50-1-86-157.dsl.dynamic.sonic.net [50.1.86.157]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 224C929408F for ; Tue, 22 Oct 2013 13:56:15 -0500 (CDT) Message-ID: <5266CA4E.5050501@agliodbs.com> Date: Tue, 22 Oct 2013 11:56:14 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Logic of lowering seq_page_cost for SSD? X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 All, I've often seen people lower seq_page_cost for SSD access. This has the effect of raising CPU costs relative to the costs of disk access. However, CPUs have also gotten lots faster, so I'm not sure that results in a better cost balance. Has anyone done extensive testing on this? What did you find? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance