Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1inmde-0001d4-Mv for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Jan 2020 16:50:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1inmdd-0002vT-4V for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Jan 2020 16:50:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1inmdc-0002of-Ki for pgsql-hackers@lists.postgresql.org; Sat, 04 Jan 2020 16:50:56 +0000 Received: from mail-yw1-xc29.google.com ([2607:f8b0:4864:20::c29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1inmdY-0001Vj-HR for pgsql-hackers@lists.postgresql.org; Sat, 04 Jan 2020 16:50:54 +0000 Received: by mail-yw1-xc29.google.com with SMTP id v126so19976693ywc.10 for ; Sat, 04 Jan 2020 08:50:51 -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=B8fvc4R0r4qtBujSAyrY224H6g7KBDikwD8HnKUidaQ=; b=uD8E0sEBAT/FOZ+eBozIVL5SFgVatzpRmaxs7Ji4IqbgpYDBg3fD5Nw14JzeZow3XD rGwhc+tVNbzP8cPx+/rMGAxtgU4nFLIDWHq1XQSEreZgKlVHbOjgjGUgedU/zvkpNFo9 FfiKWsxsd5WDX0ZqtXfvyiRJcmZMA/Vd60PEzUQ8235p9nBZnMmu4VDDaGKj9CvYByfU Oq3QJEeaTstzLCmhI6r0gAmDUVVwL5yIFgDXxA8ZkbAOzqlXqIjNaJXb980xcoN7PMiR y9eYr9pjc47qdx6ca1k6Aw0WJ17lT9jbCYer3Vuo9Mj/lFWR0IVJq6bdlFOLTspk5T1v QLug== 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=B8fvc4R0r4qtBujSAyrY224H6g7KBDikwD8HnKUidaQ=; b=FMxSLyKP+2RxQK5KhlW9shKoB7nx9uJ1+dKz2bZa/6RZeTYZJ+uB4N/fsO3iWUwQUK CGlLv5/ezQsXsatxf3gFcAXLV4VYhGVhVygoB0HYXlF3rTENFyzUznt6U4zZ7qxqgINN jCzZCkb8r5Fl//3KH0YDSfd/FcECezAe7Kgh49bZJiOAdiwBmYHA2GrC+36VNdDvDdPL +UK+Wa8GPdw+VuHn0iq+tycv/6OxTvkLKD0bnQn3npY8tQWTA4yD3hctI2SAc20uybMM AtQ21P90vHioIcoax5zLQWZUfjFXx4DhGmHnaNZU3g0xdAiktlB6XgsMy/uMCFLq9uod qUQA== X-Gm-Message-State: APjAAAVF5tPT2blssI/IN/6NWVtF4RXQ1kyiRoFSK86jSB0aEtHgayV3 UUIKEj6ldcBY2b7GVxx12DDxRQ== X-Google-Smtp-Source: APXvYqxw7V1HvMCZTwp8zSduCLVsyKWe9zOtiDUmmlanl01quVtHVIscyolO/Mape6+V0cPmguuuMw== X-Received: by 2002:a81:a190:: with SMTP id y138mr67631891ywg.343.1578156650879; Sat, 04 Jan 2020 08:50:50 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x84sm24879140ywg.47.2020.01.04.08.50.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jan 2020 08:50:49 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 0703D800964; Sat, 4 Jan 2020 10:50:47 -0600 (CST) Date: Sat, 4 Jan 2020 10:50:47 -0600 From: Justin Pryzby To: pgsql-hackers@lists.postgresql.org Cc: Jeff Janes Subject: allow disabling indexscans without disabling bitmapscans Message-ID: <20200104165047.GW12066@telsasoft.com> References: <20200103141427.GK12066@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="r7U+bLA8boMOj+mD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --r7U+bLA8boMOj+mD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Moving to -hackers I was asking about how to distinguish the index cost component of an indexscan from the cost of heap. https://www.postgresql.org/message-id/20200103141427.GK12066%40telsasoft.com On Fri, Jan 03, 2020 at 09:33:35AM -0500, Jeff Janes wrote: > > It would help to be able to set enable_bitmapscan=FORCE (to make all index > > scans go through a bitmap). > > Doesn't enable_indexscan=off accomplish this already? It is possible but > not terribly likely to switch from index to seq, rather than from index to > bitmap. (Unless the index scan was being used to obtain an ordered result, > but a hypothetical enable_bitmapscan=FORCE can't fix that). No, enable_indexscan=off implicitly disables bitmap index scans, since it does: cost_bitmap_heap_scan(): |startup_cost += indexTotalCost; But maybe it shouldn't (?) Or maybe it should take a third value, like enable_indexscan=bitmaponly, which means what it says. Actually the name is confusable with indexonly, so maybe enable_indexscan=bitmap. A third value isn't really needed anyway; its only utility is that someone upgrading from v12 who uses enable_indexscan=off (presumably in limited scope) wouldn't have to also set enable_bitmapscan=off - not a big benefit. That doesn't affect regress tests at all. Note, when I tested it, the cost of "bitmap heap scan" was several times higher than the total cost of indexscan (including heap), even with CPU costs at 0. I applied my "bitmap correlation" patch, which seems to gives more reasonable result. In any case, the purpose of this patch was primarily diagnostic, and the heap cost of index scan would be its total cost minus the cost of the bitmap indexscan node when enable_indexscan=off. The high cost attributed to bitmap heapscan is topic for the other patch. Justin --r7U+bLA8boMOj+mD Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-allow-disabling-indexscans-but-not-bitmap-scans.patch"