Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1a9azA-000589-Kv for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Dec 2015 16:00:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1a9az9-0007C5-Vz for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Dec 2015 16:00:56 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1a9az9-0007Bz-Cl for pgsql-hackers@postgresql.org; Thu, 17 Dec 2015 16:00:55 +0000 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1a9az5-0005WO-7P for pgsql-hackers@postgresql.org; Thu, 17 Dec 2015 16:00:54 +0000 Received: by mail-wm0-x22f.google.com with SMTP id p187so27448062wmp.1 for ; Thu, 17 Dec 2015 08:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=inw4S7oqG34qRkb2xSKROlSOVjxztkExkqSBZ71mDgI=; b=lQFZ6581hCGAB0+zLasFweUiLS+cRxTb+pPXN99JQ5xJn4Mh627xN0OPIt23O1VM7A o8aSc0xFchigh8wfH6wC+FsO3J1vyhDpCv+tWCB10R+Qfa4Y2D+pEDNS3iRykmBxkkbu 8KKnc6ahvwTuyJIvLolN5+j40o1yw/cJ75Jpoutr4+ULB8wSaOQAWT3CzYzauml/E7sC guLk46hwioociuXxRYmqZqUJPvf4QmWtP5iA4CZXcevlvNiKQ4SYI+gVn6H7J7cT6gvo kfziilWk29fCykV7DqUAD+dZ81ZMGYbA29An+TB+Lej05bb6KNXSr+6Fh34GB4lV2f6h SlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=inw4S7oqG34qRkb2xSKROlSOVjxztkExkqSBZ71mDgI=; b=aec4LEjuDlJ3OE+scsv13mzqpVMZfiqhn3FkGbUFDulSSX5iOAj5qGJ5RhUVf5euI+ E2rRifBZH/axdWeqv+O9nD4VRkc0hDg0WqbS+L6NA6oR8ozhk55sLvtmBUo56ehmVJm3 KjJ7V3M2JIX5yGAXj3pjjLWZ92EEYOBb+j6riadv6Wt/hc2fCmJqh5IBATrdmoJKNjvK ngR1gkezzRBLPKEcs2Pwk8jZZlkyYl/gZgYvPQ+ELDRYBQiT2JuqOdU1n1Kjei16lKer M1iW+Mnv00qmz/bJDH+7KsOMXpC+4uKISU2Q1si84+KutgFJfxEgqiSHePiQ5wXWfzwn 6SgA== X-Gm-Message-State: ALoCoQmHkrwJVZWSng3UPIvEqoxcYk+YoeoKZhTHNztRrfYLbfu/Sy2fG9DCS8CFSFq93inDA2A+OuHSOV0rCoSPnF7LYTO+kNE/jFcrggVaRnVZ2J7y3OI95DqGBq3xACC97eJUTEKyuQY9/FkJf7xo7lxxRNIzr1QQMnRJ7CoxwolS4WND27WxHPypcSx1LGTqfDITmLz+WIyLYeELv2SMSMG70FOrIA== X-Received: by 10.194.92.229 with SMTP id cp5mr58508988wjb.163.1450368049131; Thu, 17 Dec 2015 08:00:49 -0800 (PST) Received: from [10.137.2.14] (ip-89-176-99-192.net.upcbroadband.cz. [89.176.99.192]) by smtp.gmail.com with ESMTPSA id m67sm2880755wmf.16.2015.12.17.08.00.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2015 08:00:48 -0800 (PST) Subject: Re: WIP: bloom filter in Hash Joins with batches To: Simon Riggs References: <5670946E.8070705@2ndquadrant.com> Cc: PostgreSQL-development From: Tomas Vondra Message-ID: <5672DC2F.20205@2ndquadrant.com> Date: Thu, 17 Dec 2015 17:00:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 On 12/17/2015 11:44 AM, Simon Riggs wrote: > > My understanding is that the bloom filter would be ineffective in any of > these cases > * Hash table is too small Yes, although it depends what you mean by "too small". Essentially if we can do with a single batch, then it's cheaper to do a single lookup in the hash table instead of multiple lookups in the bloom filter. The bloom filter might still win if it fits into L3 cache, but that seems rather unlikely. > * Bloom filter too large Too large with respect to what? One obvious problem is that the bloom filter is built for all batches at once, i.e. for all tuples, so it may be so big won't fit into work_mem (or takes a significant part of it). Currently it's not accounted for, but that'll need to change. > * Bloom selectivity > 50% - perhaps that can be applied dynamically, > so stop using it if it becomes ineffective Yes. I think doing some preliminary selectivity estimation should not be difficult - that's pretty much what calc_joinrel_size_estimate() already does. Doing that at dynamically is also possible, but quite tricky. Imagine for example the outer relation is sorted - in that case we may get long sequences of the same value (hash), and all of them will either have a match in the inner relation, or not have a match. That may easily skew the counters used for disabling the bloom filter dynamically. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers