Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cyJDt-00088k-AC for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2017 14:26:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cyJDs-00047c-SG for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2017 14:26:16 +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 1cyJCM-0007rE-F2 for pgsql-hackers@postgresql.org; Wed, 12 Apr 2017 14:24:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cyJCJ-0002eX-RC for pgsql-hackers@postgresql.org; Wed, 12 Apr 2017 14:24:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v3CEOU1v031290; Wed, 12 Apr 2017 10:24:30 -0400 From: Tom Lane To: Alexander Kuzmenkov cc: Andrew Gierth , PostgreSQL-development Subject: Re: index-only count(*) for indexes supporting bitmap scans In-reply-to: References: <239a8955-c0fc-f506-026d-c837e86c827b@postgrespro.ru> <87ziflvryn.fsf@news-spur.riddles.org.uk> <8437.1491998661@sss.pgh.pa.us> Comments: In-reply-to Alexander Kuzmenkov message dated "Wed, 12 Apr 2017 17:01:39 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31288.1492007070.1@sss.pgh.pa.us> Date: Wed, 12 Apr 2017 10:24:30 -0400 Message-ID: <31289.1492007070@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Alexander Kuzmenkov writes: > With planner, the changes are more complex. Two things must be done > there. First, when the tlist is empty, we must use a different cost > function for bitmap heap scan, because the heap access pattern is > different. Second, choose_bitmap_and() must use a different algorithm > for choosing the right combination of paths. A standard algorithm > chooses the combination based on cost. For count(*) purposes, the > decisive factor is that the path has to check all the restrictions, or > else we'll need heap access to recheck some of them, which defeats the > purpose of having this optimization. The planner code that builds and > costs the index path is fairly complex, and integrating this additional > behavior into it didn't look good to me. TBH, I'm not sure you need to do any of that work. Have you got evidence that the planner will fail to choose the right plan regardless? I'm particularly unconvinced that choose_bitmap_and is a critical problem, because once you're into having to AND multiple indexes, you're talking about an expensive query anyhow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers