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 1iTvJa-0007VE-1b for pgsql-bugs@arkaria.postgresql.org; Sun, 10 Nov 2019 22:04:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iTvIa-0005a9-CH for pgsql-bugs@arkaria.postgresql.org; Sun, 10 Nov 2019 22:03:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iTvIZ-0005a1-T4 for pgsql-bugs@lists.postgresql.org; Sun, 10 Nov 2019 22:03:08 +0000 Received: from mail-lf1-x143.google.com ([2a00:1450:4864:20::143]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iTvIW-0001Yr-S0 for pgsql-bugs@lists.postgresql.org; Sun, 10 Nov 2019 22:03:06 +0000 Received: by mail-lf1-x143.google.com with SMTP id d6so7927664lfc.0 for ; Sun, 10 Nov 2019 14:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XgxQDhDApwHz9yBQMDezoqL8iakKgPZ6FQ4toJY/Osk=; b=fvtul606ddGrgcMnG+B3nDk2/8Ve02ZUMoZ95X7h4v1m8ESgZ4tpqJTqQ69DyaNpUA Z5NB8U/OM72+Y9uhEXNq4dnpUJHgpUnNNti0Qr778GV/HMHP2cxGRhqVYu8fZLN7QACB 6vhWaq77YFZtWDKBwrvxBUYtqbFdquLfBqdyqVyOrXoFqIxWzb/qOkVOYKmQ+wWtkZ9I f5UZORXFS0eCmyxCVYseZbGXyCm1e7Nq1G/RUFvLbzFniZpexun7t4JNfaC4URva5y5Z CRd2jyIE5u2d7tdRTdv2Kk3t2i86MHaHKHBbXR5F3cyYCpOn2fRZE3W2pLV3tSfts6i1 hwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XgxQDhDApwHz9yBQMDezoqL8iakKgPZ6FQ4toJY/Osk=; b=rAvu05Vn1mP5DQgFqXl68cY9i+x4ci6MsYQc0yU3JyRp+jHz48Fo9Pij+lXtAq5Z0p 6EHkmsnh+0ZMClIUA6p0yTTPWaI6UNuT/pWpuNEeCLBl2582VhpIECSzor/J5pgwTq/E p/nNcE4euZwETNtKZXECC32mZonrgW6S9zuHml4kQZ5M3vGo3XG0YSV6vOcKPE6/tKBA 2PGlnviMU/rk3zVUUsOw+g41f3N2aIHPxFRhJ/Rjz0bt+leRPAhTdiFwMNFx5og7s+RW DyNqe88KboPmGfVsBSKIVgl/Vy1jZ4aRoQYLPbJbAF6PJ5GjbatQaTTAkKuHxZppnDq+ q7tw== X-Gm-Message-State: APjAAAUsiv4MKqFdTUcfivzzx7IujfPAnfIL5boLYSD6mCY1uzqXx7sE /OFzQaGtPIcMLq2hknUtyNtcvQ== X-Google-Smtp-Source: APXvYqxvlUYkQ9VYVDpq6fZ9eeoMwdOmf/fvD+iSoyTQ79coTRR8X/WQeTCFfNtDwjPyiVVtOoHZBg== X-Received: by 2002:a19:9116:: with SMTP id t22mr303850lfd.99.1573423383311; Sun, 10 Nov 2019 14:03:03 -0800 (PST) Received: from localhost ([217.8.174.100]) by smtp.gmail.com with ESMTPSA id b4sm6349589ljp.84.2019.11.10.14.03.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Nov 2019 14:03:00 -0800 (PST) Date: Sun, 10 Nov 2019 23:02:59 +0100 From: Tomas Vondra To: Tom Lane Cc: Thomas Munro , James Coleman , PostgreSQL mailing lists Subject: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash Message-ID: <20191110220259.r4x6zon4zjjxz2vj@development> References: <20191109182735.ewficcv2hibbyzl4@development> <20191110172925.mlkglpwzwego3wtp@development> <8966.1573421649@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8966.1573421649@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Nov 10, 2019 at 04:34:09PM -0500, Tom Lane wrote: >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. > That's not quite correct - it's a solution/improvement as long as the values have more than 32 bits of information. I.e. it works even for values that are less than 64 bits wide, as long as there's more than 32 bits of information (assuming the hash does not lost the extra bits). In the case discussed in this text we're dealing with a citext column, with average length ~8 chars. So it probably has less than 64 bits of information, because it's likely just alphanumeric, or something like that. But likely more than 32 bits. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services