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 1gwMsT-0003JD-Aq for pgsql-performance@arkaria.postgresql.org; Wed, 20 Feb 2019 08:05:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gwMsQ-0006E4-Dp for pgsql-performance@arkaria.postgresql.org; Wed, 20 Feb 2019 08:05:10 +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 1gwMsP-000684-Um for pgsql-performance@lists.postgresql.org; Wed, 20 Feb 2019 08:05:10 +0000 Received: from mail-it1-x144.google.com ([2607:f8b0:4864:20::144]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwMsK-0007T4-J6 for pgsql-performance@lists.postgresql.org; Wed, 20 Feb 2019 08:05:08 +0000 Received: by mail-it1-x144.google.com with SMTP id r11so13254667itc.2 for ; Wed, 20 Feb 2019 00:05:04 -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=O3a+hGSRZRlhYQmzrVRuu5aXV2DeaaVQr/Qjb4wiNaA=; b=HPbU85d0bUgeNBTmvIdQZhrrEkxC6b9lUvyOuazNiZatp1tAaJKCqoLszSBtccUGLg BA7CT83Gdt1XwYjhFT5kG4Rv3Im7vFK7oQjJ8Sadl2HUMPSKy/BVyvjs5vbCa0QzJUdv AG9vdTin8Xma6tTYXn8PkAZJqVUxvdEaSSRjNNVLSj1Z6rHMrEE0jrBtlicmQerW4ETE e1EzCD2nKpaOQukYORWmMEZhd1vTO6/AJMXaM7s88KWokrhex/LGcXKYrKNSIYA45yEt JNKSKQt1o+RSO5smhtns8C+R4JxdqiCJUHxfj9ABh2W7OY+TZLz2gt3uvK4fjWMAWycK hLbg== 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=O3a+hGSRZRlhYQmzrVRuu5aXV2DeaaVQr/Qjb4wiNaA=; b=sYu2gtA0mYsFnU35bw6urXM/K6vfA10bGQD5dkOY26gkX8/3lSZyDIhvz4iNycuMcQ lruelT7/sdp2ZR7HLP27VBC11KewrJA3CmtDY7RAR5Sb/w4h1gG3NVSPmYLB2k9xbwni RutAydGe9v7yzhdReNmhSnjR5tN9UkJ5fa8SO3M9b/5K+WP4Qx3G/VBbKAaK7xlWwPOJ s7Iw3NkAuCm4minAwkwInGGe5CDVKcnMQ2VWsqMF8XYCKADD7oPdYzDGaiCe4jTmCAHr 2YEKHK61J65hDj1FhgGoaUcWmzana9IPvOWUiIdmSoVERP+RnJZ5LN7xtW6BZNSdLzg6 L1ig== X-Gm-Message-State: AHQUAuZDZzKmaom2Hs+C5CwF8oPoYbxGuq1yIgN7DNeeFqti4jZPO1BN hsyQPThP1dnOKzsEkdIjaU7Mpg== X-Google-Smtp-Source: AHgI3Ia1akC+nlB64mFEWKnO+SuQJsjTDgSxiu6tyv0Mh5GnY0xIbUKdEJ2kus5G5zbiVluUZAkn4w== X-Received: by 2002:a24:2b8c:: with SMTP id h134mr5290370ita.53.1550649903563; Wed, 20 Feb 2019 00:05:03 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x7sm7654248ioh.51.2019.02.20.00.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 00:05:02 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 19455800BD7; Wed, 20 Feb 2019 02:05:01 -0600 (CST) Date: Wed, 20 Feb 2019 02:05:00 -0600 From: Justin Pryzby To: Michael Lewis Cc: Andrew Gierth , Abi Noda , pgsql-performance@lists.postgresql.org Subject: Re: Why isn't an index scan being used? Message-ID: <20190220080500.GO28750@telsasoft.com> References: <87ftsji2tb.fsf@news-spur.riddles.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Tue, Feb 19, 2019 at 09:29:46PM -0700, Michael Lewis wrote: > On Tue, Feb 19, 2019, 8:00 PM Andrew Gierth wrote: > > > >>>>> "Abi" == Abi Noda writes: > > Abi> However, when I index the closed column, a bitmap scan is used > > Abi> instead of an index scan, with slightly slower performance. Why > > Abi> isn't an index scan being used, given that the exact same number > > Abi> of rows are at play as in my query on the state column? > > > > Most likely difference is the correlation estimate for the conditions. > > The cost of an index scan includes a factor based on how well correlated > > the physical position of rows is with the index order, because this > > affects the number of random seeks in the scan. But for nulls this > > estimate cannot be performed, and bitmapscan is cheaper than plain > > indexscan on poorly correlated data. > > Does this imply that the optimizer would always prefer the bitmapscan > rather than index scan even if random page cost = 1, aka sequential cost, > when the correlation is unknown like a null? Or only when it thinks random > access is more expensive by some significant factor? No; for one, since for a bitmap scan, the heap scan can't begin until the index scan is done, so there's a high(er) initial cost. Otherwise bitmap scan could always be used and all access could be ordered (even if not sequential). Justin