Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eL1UI-0003Ek-Pr for pgsql-performance@arkaria.postgresql.org; Sat, 02 Dec 2017 06:41:23 +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 1eL1UG-00042R-Hp for pgsql-performance@arkaria.postgresql.org; Sat, 02 Dec 2017 06:41:20 +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 1eL1UG-00042D-3w for pgsql-performance@lists.postgresql.org; Sat, 02 Dec 2017 06:41:20 +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 1eL1UC-0003GI-VH for pgsql-performance@lists.postgresql.org; Sat, 02 Dec 2017 06:41:18 +0000 Received: by mail-io0-x22a.google.com with SMTP id w127so13551518iow.11 for ; Fri, 01 Dec 2017 22:41:16 -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:content-transfer-encoding:in-reply-to :user-agent; bh=LzXxdtXr/jIaYnghQIQBCIpsHAnioNPySZ/JxB0aVaM=; b=1z8Tx6ZwJdBigpXr3AHoPArYphs6PD2UrsZwfy6nkGrxq2xlcfqhBZoadkeyTEDlwm L9XEXhYgB0cvGwOA4oTNlLZ3myJCJIqxMipAJBOChbyStkShfPAsRyvi0WiRh+jpufUY 75VJEinScUtwbo+htAGJSCO1EqROe10g2TWKBVE9sYT/3jl4erfC2Ssy16Y2Uzi6Iwut ahPIOiDZKOxRYZW6M53ZXK5wgHuUOVKvVdJNNYR+i6YWvIwJg1idurqi165YHil1rLGl ZXX4o8EtPB7iXvkTN8mVW3jEz1uXfDyBG+3Qnl4jeZxyx7jOGX2J58NxV3ILfCSaLeWR QNjA== 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:content-transfer-encoding :in-reply-to:user-agent; bh=LzXxdtXr/jIaYnghQIQBCIpsHAnioNPySZ/JxB0aVaM=; b=eKXNA906Rm2kyXQeN9DKTly5Cyq21zPKLglE+UEw+GxH2+CBqP8RuDWw6PBNmFVwHa hBRtTFJhIwREjSS8nYmJFPt3i8oOHz/o4qt1Y0JY2oKM2y0XhQjlO0YXDMiwkFnrCkAV VqVnrJBwXC0gM8LKD1bp3c+nDviAMNqV2nu/UomJmaxvPuW+vAHDWFJLPg5MQn46mcRl 63dpTfmHhL6I2x8cdtobnKdrNbbKZfv0cJQuDlarEITpKnV2/2z3hd1CwuCn4//kD1Nl TqTRGev9JbOkDHlu9l4LAzkOarA/lRpQ0h6sgS3pNNhB4ADPO0DDobXMOOv34SLJtBos IxIQ== X-Gm-Message-State: AJaThX7V8Zh0j3FQpa0F7argn2Xkxmu0cQG5MeviiNLyEzBz6803JsUN vpI+g7RK8mp2JBYvGF6S5PL19g== X-Google-Smtp-Source: AGs4zMaI1U9MeWYDn54+xiw3hUVSskX3jBsfsNO3CpfMNXpmo8XlvWmAK9h95nwvTXMpKA3pzd/3MA== X-Received: by 10.107.170.42 with SMTP id t42mr14759841ioe.228.1512196875783; Fri, 01 Dec 2017 22:41:15 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id z19sm4038574iof.53.2017.12.01.22.41.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 22:41:15 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id D7444801058; Sat, 2 Dec 2017 00:41:13 -0600 (CST) Date: Sat, 2 Dec 2017 00:41:13 -0600 From: Justin Pryzby To: Vitaliy Garnashevich Cc: pgsql-performance@lists.postgresql.org Subject: Re: Bitmap scan is undercosted? Message-ID: <20171202064113.GP18413@telsasoft.com> References: <73a4936d-2814-dc08-ed0c-978f76f435b0@gmail.com> <20171201183427.GK18413@telsasoft.com> <20171201231104.GN18413@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Dec 02, 2017 at 01:54:09AM +0200, Vitaliy Garnashevich wrote: > On 02/12/2017 01:11, Justin Pryzby wrote: > >..which is what's wanted with no planner hints (PG10.1 here). > Yes, that's what you get without planner hints, but it's strange to get this > plan, when there is another one, which runs 2-3 times faster, but happens to > be estimated to be twice more costly than the one with bitmap scans: > > # set enable_bitmapscan = off; set enable_indexscan = on;  set enable_seqscan = off; > # explain analyze select * from aaa where num = 1 and flag = true; > Index Scan using i1 on aaa  (cost=0.44..66369.81 rows=10428 width=5) (actual time=0.020..57.765 rows=100000 loops=1) > > vs. > > # set enable_bitmapscan = on;  set enable_indexscan = off; set enable_seqscan = off; > # explain analyze select * from aaa where num = 1 and flag = true; > Bitmap Heap Scan on aaa  (cost=13099.33..25081.40 rows=10428 width=5) (actual time=122.137..182.811 rows=100000 loops=1) I was able to get an index plan with: SET random_page_cost=1; SET cpu_index_tuple_cost=.04; -- default: 0.005; see selfuncs.c postgres=# EXPLAIN (analyze,verbose,costs,buffers) SELECT * FROM aaa WHERE num=1 AND flag=true; Index Scan using i1 on public.aaa (cost=0.43..50120.71 rows=10754 width=5) (actual time=0.040..149.580 rows=100000 loops=1) Or with: SET random_page_cost=1; SET cpu_operator_cost=0.03; -- default: 0.0025 see cost_bitmap_tree_node() EXPLAIN (analyze,verbose,costs,buffers) SELECT * FROM aaa WHERE num=1 AND flag= true; Index Scan using i1 on public.aaa (cost=5.22..49328.00 rows=10754 width=5) (actual time=0.051..109.082 rows=100000 loops=1) Or a combination trying to minimize the cost of the index scan: postgres=# SET random_page_cost=1; SET cpu_index_tuple_cost=.0017; SET cpu_operator_cost=0.03; EXPLAIN (analyze,verbose,costs,buffers) SELECT * FROM aaa WHERE num=1 AND flag= true; Index Scan using i1 on public.aaa (cost=5.22..48977.10 rows=10754 width=5) (actual time=0.032..86.883 rows=100000 loops=1) Not sure if that's reasonable, but maybe it helps to understand. Justin