Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKxC5-0006fE-Ks for pgsql-performance@arkaria.postgresql.org; Sat, 02 Dec 2017 02:06:17 +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 1eKxC3-0004XY-N1 for pgsql-performance@arkaria.postgresql.org; Sat, 02 Dec 2017 02:06:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eKxC3-0004XP-CE for pgsql-performance@lists.postgresql.org; Sat, 02 Dec 2017 02:06:15 +0000 Received: from mail-it0-x22e.google.com ([2607:f8b0:4001:c0b::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eKxBv-0005Dr-F7 for pgsql-performance@lists.postgresql.org; Sat, 02 Dec 2017 02:06:14 +0000 Received: by mail-it0-x22e.google.com with SMTP id d137so4466838itc.2 for ; Fri, 01 Dec 2017 18:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent:from; bh=vg6RQh4LUhvimoTkSVTfEUzVXIce/c85VLVFnwPcHvM=; b=JcabAhyVDuUtlAaM2OAaz7WmH9GxZneHO+PjSaa578/8RbC+P2nWSezSXozfU8U+0i 9U47hLlwdARQudwpj4owFavGmhW6QnTGl8ZvFmA4FMHwgH1TOw5qmkTkbRNXw9QLVNby s8EtdTjwymKVjcLUTa6EgWUcrYUPRIMQk9PCxL6TGy2MY340qyGVoWxR64Yo5z8rBIch epkM7ySlwdtO+ECFOGJy5oJNcGSgE5L2xhSA0Blttf85705G2UE4DCMCbR1FcsfnA40J YO8cdQGybPigThu7Be4fKd8K16zTGuQADkVkUEERSzJ+HKRN5CFeMCW/uBHDL/hMSqaF n1NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent:from; bh=vg6RQh4LUhvimoTkSVTfEUzVXIce/c85VLVFnwPcHvM=; b=KKKxgrpth2ORI6hWIRrHwEMXga87MDyD2NJwxEn/6ORx/N4ytsavqdvtG2pP5/a289 3CJ9+tyoi3QCGQ9L1d6t9iv/pXiEi9Lv/uNaqx19/2tnI5po4BAfErnT1I9zQf/Nxf+O uqY1GIUv6zK/P/J0Ci9bgrZ1DSeNO8rcArW3T/Big6CyDHxvmxOHsCToLaPY5UY07xMi fgAhxRJgeyvjPTAA5KOtxQbhYB/Kkkbp/CBylFfHgwBNErAbgdMYD7iJS+sTXYcN68LX uHdC59DdaMHhxLCtwVmtTcTF/U3dFuNpU7Ndfs0BCM7ZTB7TGrYf0YaX9p+AhBxZnzFB r75A== X-Gm-Message-State: AKGB3mJWehLDieajALyY6/uJaWmHNA4XHRGOfmyEZTOOx6ojZvQYHw2l 3nuMPPccHJGDdKNC4dtqcmk1aA== X-Google-Smtp-Source: AGs4zMagAMyw/HwvAY16JbBLgJF69btQWgLPpapKssKvf4QZYKw4+VvTBRtrY+GFNzybw1V6C1oqfw== X-Received: by 10.36.71.84 with SMTP id t81mr4818629itb.63.1512180365108; Fri, 01 Dec 2017 18:06:05 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id f11sm3651226iob.52.2017.12.01.18.06.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 18:06:04 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 8D5A480102B; Fri, 1 Dec 2017 20:06:03 -0600 (CST) Date: Fri, 1 Dec 2017 20:06:03 -0600 To: Vitaliy Garnashevich Cc: pgsql-performance@lists.postgresql.org Subject: Re: Bitmap scan is undercosted? Message-ID: <20171202020603.GO18413@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171201231104.GN18413@telsasoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) From: pryzby@telsasoft.com (Justin Pryzby) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Dec 01, 2017 at 05:11:04PM -0600, Justin Pryzby wrote: > I tried to reproduce this issue and couldn't, under PG95 and 10.1: I'm embarassed to say that I mis-read your message, despite you're amply clear subject. You're getting a bitmap scan but you'd prefer to get an index scan. I anticipated the opposite problem (which is what I've had issues with myself). > On Fri, Dec 01, 2017 at 12:34:27PM -0600, Justin Pryzby wrote: > > On Fri, Dec 01, 2017 at 07:40:08PM +0200, Vitaliy Garnashevich wrote: > > > We recently had an issue in production, where a bitmap scan was chosen > > > instead of an index scan. Despite being 30x slower, the bitmap scan had > > > about the same cost as the index scan. > > Note: > postgres=# SELECT correlation FROM pg_stats WHERE tablename='aaa' AND attname='num'; > correlation | 0.00710112 > > ..so this is different from the issue corrected by the patch I created while > testing. Actually, that the table is "not correlated" on "num" column is maybe the primary reason why PG avoids using an index scan. It (more or less correctly) deduces that it's going to have to "read" a large fraction of the pages (even if only to process a small fraction of the rows), which is costly, except it's all cached.. In your case, that overly-penalizes the index scan. This is cost_index() and cost_bitmap_heap_scan() in costsize.c. Since the index is uncorrelated, it's returning something close to max_IO_cost. It looks like effective_cache_size only affects index_pages_fetched(). I'm going to try to dig some more into it. Maybe there's evidence to re-evaluate one of these: cost_index() | run_cost += max_IO_cost + csquared * (min_IO_cost - max_IO_cost); or cost_bitmap_heap_scan() | cost_per_page = spc_random_page_cost - | (spc_random_page_cost - spc_seq_page_cost) | * sqrt(pages_fetched / T); Justin