Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXHfz-00049Y-UG for pgsql-performance@arkaria.postgresql.org; Wed, 10 Aug 2016 00:47:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bXHfy-0001ZZ-LB for pgsql-performance@arkaria.postgresql.org; Wed, 10 Aug 2016 00:47:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bXHeI-0007bh-Ps for pgsql-performance@postgresql.org; Wed, 10 Aug 2016 00:45:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bXHeB-0000SR-Cf for pgsql-performance@postgresql.org; Wed, 10 Aug 2016 00:45:34 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u7A0jNsZ012339; Tue, 9 Aug 2016 20:45:23 -0400 From: Tom Lane To: Suya Huang cc: Claudio Freire , "pgsql-performance@postgresql.org" Subject: Re: what's the slowest part in the SQL In-reply-to: References: <1D0FF65A-EAB9-453C-9B95-684E05B494B7@connexity.com> <001EBA46-372C-4325-9AC5-168E19949C8A@connexity.com> Comments: In-reply-to Suya Huang message dated "Wed, 10 Aug 2016 00:34:38 -0000" Date: Tue, 09 Aug 2016 20:45:23 -0400 Message-ID: <12338.1470789923@sss.pgh.pa.us> X-Pg-Spam-Score: -2.3 (--) 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 Suya Huang writes: > -> Index Scan using idx_order_1_us on order o (cost=0.56..8.58 rows=1 width=30) (actual time=5.814..5.814 rows=0 loops=526) 4 or so ms per row fetched is well within expectation for random access to spinning-rust media. For example, a 15K RPM drive spins at 4 ms per revolution, so rotational delay alone would probably explain this number, never mind needing to do any seeks. So I see nothing even slightly unexpected here, assuming that the "order" table is large enough that none of what you need is in RAM already. If you need more performance, look into SSDs. (If you have storage kit for which you'd expect better performance than this, you should start by explaining what it is.) regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance