Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1a9aa5-0003tb-QJ for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Dec 2015 15:35:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1a9aa5-0006H1-1w for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Dec 2015 15:35:01 +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) (envelope-from ) id 1a9aa4-0006Fb-3a for pgsql-hackers@postgresql.org; Thu, 17 Dec 2015 15:35:00 +0000 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1a9aZw-0005tN-2J for pgsql-hackers@postgresql.org; Thu, 17 Dec 2015 15:34:59 +0000 Received: by mail-wm0-x22e.google.com with SMTP id l126so28722092wml.1 for ; Thu, 17 Dec 2015 07:34: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=lRWrtop1F2CadHzWl9xfHHTytMMmNM4URDVTNeeaReM=; b=yzRjWjQ2/BHr3QpFGFJRJRMriNgxit8qicxm6otHnwPWesUOmgRjiyHa6znQsNG7dP o+GcIDAS2MWYtLT/TXLwnpMhufMqsCGeSw/FERU8BzZN4HPLmUsaZLqBEo7joGIS8po7 abtA7Op9e8m4rEQQncTalKBtVRW5CxupEiNJkrPvt1bxpYJx2Rz0640cxbCT1oPWrZHk Bm6DN40WD/0IHW+wJ15fuVN90QU9LqMRsD0XbYy8M6A3oNpYJ6X/0DJ/JNvHJugty3R+ g5Sl+HhoghJqMloXtyb5WkQkGGM3eXemie4vHKK3sTyQd6t2N+/JATNh3X0EUKzVeS9R vhSA== 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=lRWrtop1F2CadHzWl9xfHHTytMMmNM4URDVTNeeaReM=; b=fFdMZROWt4ARikI/lBpYR3IVIAkbZUhBHbfcbZxPQZJVtoo/BC4QJxQhWf66epNbtX jKs+lD6dU07HOq0lJ5Ar3DVEMAbY8TSqjvPgLrMvpZpHmGcmTKoFh4JCQdxHtQ1LuY/b voPIur0+uzWJx3ePjVA85RcJSiAVQSWqRo2FCTK64VnV/6W7ulnoalhKM6z0jQ5B+rNQ ElfIJ/ndqMHSjp1g1UkMZvQfxLN55tpk05mIr+eKx+KC1os4StCjoFR4Uu+4AYNfIFwn P9nyheQfZL07Uw6CgsfdMa0iodryKjkEHC899lXBnwuDwd1mvdjTGvxY7P+P6ZyyEvPn DHHA== X-Gm-Message-State: ALoCoQlNn/dXTSsUkuSD+PvvdO5QE41OK3cEKt7gNkvpB/7hS1schvOKlsnduzaYshzTQr6eeSKkG+6yOk+OI9AV5gfSO046GnmJzvQHvjPl7wKPZokA3JrEueblxW/FfwT3/oDxZwOHyBUhHVmmsEU4ccWGNOX0plD8eII9oglm8L0kBlQ7n1Pq8DW8gzoxo0dkgl7btJgWSNL6AO0cR/J1wLCt1jusdg== X-Received: by 10.194.77.51 with SMTP id p19mr56863088wjw.159.1450366490079; Thu, 17 Dec 2015 07:34:50 -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 c13sm2798385wmd.14.2015.12.17.07.34.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2015 07:34:49 -0800 (PST) Subject: Re: WIP: bloom filter in Hash Joins with batches To: "Shulgin, Oleksandr" References: <5670946E.8070705@2ndquadrant.com> Cc: PostgreSQL Hackers From: Tomas Vondra Message-ID: <5672D617.9060601@2ndquadrant.com> Date: Thu, 17 Dec 2015 16:34: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 Hi, On 12/17/2015 10:50 AM, Shulgin, Oleksandr wrote: > On Tue, Dec 15, 2015 at 11:30 PM, Tomas Vondra > > wrote: > >> Attached is a spreadsheet with results for various work_mem >> values, and also with a smaller data set (just 30M rows in the fact >> table), which easily fits into memory. Yet it shows similar gains, >> shaving off ~40% in the best case, suggesting that this is not just >> thanks to reduction of I/O when forcing the temp files to disk. > > A neat idea! Have you possibly tried to also collect statistics > about actual false-positive rates and filter allocation sizes in > every of the collected data points? The patch counts and prints the total number of lookups, and the number of eliminated rows. The bloom filter is currently sized for 5% false positives rate, and the numbers I've seen match that. I think ultimately we'll need to measure the false positive rate, so that we can use it to dynamically disable the bloom filter if it gets inefficient. Also maybe put some of that into EXPLAIN ANALYZE. 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