Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLdji-0005DU-Ko for pgsql-performance@arkaria.postgresql.org; Sun, 03 Dec 2017 23:31:50 +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 1eLdji-0002cg-3l for pgsql-performance@arkaria.postgresql.org; Sun, 03 Dec 2017 23:31:50 +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 1eLdjh-0002cX-Tb for pgsql-performance@lists.postgresql.org; Sun, 03 Dec 2017 23:31:49 +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.89) (envelope-from ) id 1eLdja-0002PJ-Oa for pgsql-performance@lists.postgresql.org; Sun, 03 Dec 2017 23:31:49 +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 vB3NVePG012767; Sun, 3 Dec 2017 18:31:40 -0500 From: Tom Lane To: Jeff Janes cc: Justin Pryzby , Vitaliy Garnashevich , pgsql-performance@lists.postgresql.org Subject: Re: Bitmap scan is undercosted? - boolean correlation In-reply-to: References: <73a4936d-2814-dc08-ed0c-978f76f435b0@gmail.com> <20171201183427.GK18413@telsasoft.com> <20171201231104.GN18413@telsasoft.com> <18188.1512258290@sss.pgh.pa.us> <20171203040430.GC14008@telsasoft.com> Comments: In-reply-to Jeff Janes message dated "Sun, 03 Dec 2017 15:21:56 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12765.1512343900.1@sss.pgh.pa.us> Date: Sun, 03 Dec 2017 18:31:40 -0500 Message-ID: <12766.1512343900@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Jeff Janes writes: > On Sat, Dec 2, 2017 at 8:04 PM, Justin Pryzby wrote: >> It thinks there's somewhat-high correlation since it gets a list of x >> and y values (integer positions by logical and physical sort order) and >> 90% of the x list (logical value) are the same value ('t'), and the >> CTIDs are in order on the new index, so 90% of the values are 100% >> correlated. > But there is no index involved (except in the case of the functional > index). The correlation of table columns to physical order of the table > doesn't depend on the existence of an index, or the physical order within > an index. > But I do see that ties within the logical order of the column values are > broken to agree with the physical order. That is wrong, right? Is there > any argument that this is desirable? Uh ... what do you propose doing instead? We'd have to do something with ties, and it's not so obvious this way is wrong. regards, tom lane