Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQHz1-0006RT-FM for pgsql-performance@arkaria.postgresql.org; Sat, 16 Dec 2017 19:18:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQHz0-0002fG-Ih for pgsql-performance@arkaria.postgresql.org; Sat, 16 Dec 2017 19:18:50 +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 1eQHz0-0002f7-7A for pgsql-performance@lists.postgresql.org; Sat, 16 Dec 2017 19:18:50 +0000 Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eQHyt-00045R-Ng for pgsql-performance@lists.postgresql.org; Sat, 16 Dec 2017 19:18:48 +0000 Received: by mail-io0-x22a.google.com with SMTP id x129so5946212iod.13 for ; Sat, 16 Dec 2017 11:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=R9Hj3yYs02rfq0Ew4zxbdBSk/CAIlqS5w5AYMXOvVr8=; b=wj4ArrXGA3fXf+Fhk3eS35xDC99nEkhuwhDgIBlN6sugAy/xPiuvWWfFb3k/r/LgOM Zeg7Hl+R+gKwhT6eNaoPdEmxk0xM9VDrw3dkoYKNq3pFgAmcuHdtRnInyOgWvgtDuJ7n VEz+ed+iFh5zZU4M/gtgidF5lrYTRTcC8Qi2JiRS75J7POgWCBiOUhBJPOxh1Ewl2bkk mCDhPZ5yLHMiK2glz2DxY32yItZsgAVuRjc/5LoRuTvpQwWWrleRm492wvEQ7CRql5ub YGc8PANbqkrCXsL1zyhQ8Q/w/b/jdWUdL2Lek9cWkeIUJX+zF3yTqc2+fCvNnFygx/A5 nSxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=R9Hj3yYs02rfq0Ew4zxbdBSk/CAIlqS5w5AYMXOvVr8=; b=agT5cetEJweIdV7NMSlZJoma+vTjC4GzsynjxexjXfQwlXVxgB6WbqiaanYFmdsQEO 3ZcWuaJLzBPTPvcqw0F9Za6kA+z1JvWJrqH6p81xl25HM6ddH+niKgTsMHDco3o0efVx 8dzxcjXovyeBIRCaqZAa/0coQtR1gs/0X78iQt1tZJqqsJPUxm91AsKwzCIyvU28q3zM b2KA7phWbiPZQsNUxy3C0nqZlJrDOSKI9rdXAUfR/+JXIhcZg0uaTrTIZuZLhZ9+jh72 VLPSyLQbsQy1e3qK2MeWvhqSqkr4cvrKuKu4X/BfxEAemX23W+VB2HbLDWpkt2UDxACD xPoQ== X-Gm-Message-State: AKGB3mJTs8SnoIWjZiLeRDvkta2Ny4BwrO9sabfvhc5ai9xclKslP+nt QtPWHJW0KeJIdcbRy21kd8cUtw== X-Google-Smtp-Source: ACJfBov4hRFqjN1fZOSxv9LMyMh4dIHWy5Jk2yPEai/MUJQhvDzcLGJAcU4cZmhDldCkkAUksFeJpA== X-Received: by 10.107.139.12 with SMTP id n12mr17618028iod.1.1513451922125; Sat, 16 Dec 2017 11:18:42 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id c23sm346158iod.5.2017.12.16.11.18.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Dec 2017 11:18:41 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id DB06580105E; Sat, 16 Dec 2017 13:18:38 -0600 (CST) Date: Sat, 16 Dec 2017 13:18:38 -0600 From: Justin Pryzby To: Jeff Janes Cc: Tom Lane , Vitaliy Garnashevich , pgsql-performance@lists.postgresql.org Subject: Re: Bitmap scan is undercosted? - overestimated correlation and cost_index Message-ID: <20171216191838.GA16769@telsasoft.com> References: <18188.1512258290@sss.pgh.pa.us> <20171203040430.GC14008@telsasoft.com> <12766.1512343900@sss.pgh.pa.us> <14438.1512499811@sss.pgh.pa.us> <20171206214652.GA13889@telsasoft.com> <20171215205406.GN18184@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171215205406.GN18184@telsasoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Dec 15, 2017 at 02:54:06PM -0600, Justin Pryzby wrote: > SSD: good question. > > Here's an rackspace VM with PG9.6.6, 2GB shared_buffers, 8GB RAM (~4GB of which > is being used as OS page cache), and 32GB SSD (with random_page_cost=1). The > server is in use by our application. > > I believe you could scale up the size of the table to see this behavior with > any cache size. 0.0001 controls the "jitter", with smaller values being more > jittery.. > > postgres=# CREATE TABLE t(i int,j int) TABLESPACE tmp; CREATE INDEX ON t(i); INSERT INTO t SELECT (0.0001*a+9*(random()-0.5))::int FROM generate_series(1,99999999) a; VACUUM ANALYZE t; > public | t | table | pryzbyj | 3458 MB | > relpages | 442478 I realized I've made a mistake here; the table is on SSD but not its index... So all this cost is apparently coming from the index and not the heap. -> Bitmap Heap Scan on t (cost=855041.91..1901994.06 rows=40298277 width=4) (actual time=14202.624..27754.982 rows=40009853 loops=1) -> Bitmap Index Scan on t_i_idx1 (cost=0.00..844967.34 rows=40298277 width=0) (actual time=14145.877..14145.877 rows=40009853 loops=1) Let me get back to you about that. Justin