Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdgbT-0007hW-IE for pgsql-performance@arkaria.postgresql.org; Sat, 27 Aug 2016 16:37:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bdgbS-0003QG-E2 for pgsql-performance@arkaria.postgresql.org; Sat, 27 Aug 2016 16:37:06 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bdgbR-0003Pi-DI for pgsql-performance@postgresql.org; Sat, 27 Aug 2016 16:37:05 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bdgbN-0004CP-Ly for pgsql-performance@postgresql.org; Sat, 27 Aug 2016 16:37:04 +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 u7RGauG1006956; Sat, 27 Aug 2016 12:36:56 -0400 From: Tom Lane To: Craig James cc: Jim Nasby , Mike Sofen , "pgsql-performance@postgresql.org" Subject: Re: Slow query with big tables In-reply-to: References: <00e601d1ffd8$2beb8850$83c298f0$@runbox.com> <1b6396d4-ca7d-05a1-51c7-3b1d71c6cd55@BlueTreble.com> Comments: In-reply-to Craig James message dated "Sat, 27 Aug 2016 07:13:00 -0700" Date: Sat, 27 Aug 2016 12:36:56 -0400 Message-ID: <6955.1472315816@sss.pgh.pa.us> X-Pg-Spam-Score: -2.1 (--) 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 Craig James writes: > Straight hash-table indexes (which Postgres doesn't use) have O(1) access > time. The amount of data has no effect on the access time. This is wishful thinking --- once you have enough data, O(1) goes out the window. For example, a hash index is certainly not going to continue to scale linearly once you reach its maximum possible number of buckets (2^N for N-bit hashes, and remember you can't get very many useful hash bits out of small objects like integers). But even before that, large numbers of buckets put enough stress on your storage system that you will see some not very O(1)-ish behavior, just because too little of the index fits in whatever cache and RAM you have. Any storage hierarchy is ultimately going to impose O(log N) access costs, that's the way they're built. I think it's fairly pointless to discuss such matters in the abstract. If you want to make useful engineering tradeoffs you have to talk about specific data sets and available hardware. 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