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 1iTuqg-0006cn-Si for pgsql-bugs@arkaria.postgresql.org; Sun, 10 Nov 2019 21:34:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iTuqe-0004eK-PH for pgsql-bugs@arkaria.postgresql.org; Sun, 10 Nov 2019 21:34: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_SHA1:256) (Exim 4.89) (envelope-from ) id 1iTuqe-0004eD-Hp for pgsql-bugs@lists.postgresql.org; Sun, 10 Nov 2019 21:34:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iTuqc-0002a3-1p for pgsql-bugs@lists.postgresql.org; Sun, 10 Nov 2019 21:34:16 +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 xAALY9vn008967; Sun, 10 Nov 2019 16:34:09 -0500 From: Tom Lane To: Thomas Munro cc: James Coleman , Tomas Vondra , PostgreSQL mailing lists Subject: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash In-reply-to: References: <20191109095456.csw3f5rhc364z5fg@development> <20191109182735.ewficcv2hibbyzl4@development> <20191110172925.mlkglpwzwego3wtp@development> Comments: In-reply-to Thomas Munro message dated "Mon, 11 Nov 2019 10:08:58 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8965.1573421649.1@sss.pgh.pa.us> Date: Sun, 10 Nov 2019 16:34:09 -0500 Message-ID: <8966.1573421649@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > I think I see what's happening: we're running out of hash bits. Ugh. > Besides switching to 64 bit hashes so that we don't run out of > information (clearly a good idea), what other options do we have? If the input column is less than 64 bits wide, this is an illusory solution, because there can't really be that many independent hash bits. I think we need to have some constraint that keeps us from widening the batch+bucket counts to more hash bits than we have. regards, tom lane