Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRJmx-0003jw-8b for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Aug 2022 20:49:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oRJmu-0004AO-L1 for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Aug 2022 20:49:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRJmu-00049a-CA for pgsql-bugs@lists.postgresql.org; Thu, 25 Aug 2022 20:49:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRJmp-00071y-9C for pgsql-bugs@lists.postgresql.org; Thu, 25 Aug 2022 20:49:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 27PKn9jk1573190; Thu, 25 Aug 2022 16:49:09 -0400 From: Tom Lane To: maxim.boguk@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17594: conditional hash indexes size (hash index ignore WHERE condition during CREATE INDEX?) In-reply-to: <17594-fca95086967695be@postgresql.org> References: <17594-fca95086967695be@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 25 Aug 2022 20:19:54 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1573188.1661460549.1@sss.pgh.pa.us> Date: Thu, 25 Aug 2022 16:49:09 -0400 Message-ID: <1573189.1661460549@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > I found very weird situation with size of highly selective partial hash > indexes (they has almost same size as full table hash index). hashbuild() sets up the initial hash index size based on estimating the current number of rows in the table, without any correction for partial-index selectivity. I don't find this to be a bug particularly. The odds of making things worse via a bad estimate seem at least as high as the odds of making things better. regards, tom lane