Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 9BA94B5DBC4 for ; Tue, 4 Oct 2011 05:13:10 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 55565-07 for ; Tue, 4 Oct 2011 08:13:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mail.postgresql.org (Postfix) with ESMTP id 2757BB5D8C5 for ; Tue, 4 Oct 2011 05:13:02 -0300 (ADT) Received: from mail-bw0-f48.google.com ([209.85.214.48]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 01:13:03 PDT Received: by mail-bw0-f48.google.com with SMTP id zu5so353225bkb.7 for ; Tue, 04 Oct 2011 01:13:01 -0700 (PDT) Received: by 10.204.141.80 with SMTP id l16mr545256bku.183.1317715981432; Tue, 04 Oct 2011 01:13:01 -0700 (PDT) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi. [88.195.122.240]) by mx.google.com with ESMTPS id t13sm8794240fae.0.2011.10.04.01.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 01:12:58 -0700 (PDT) Message-ID: <4E8AC009.5040806@enterprisedb.com> Date: Tue, 04 Oct 2011 11:12:57 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: Alexander Korotkov CC: pgsql-hackers Subject: Re: Double sorting split patch References: <4E72197B.9040602@enterprisedb.com> <4E732DFF.9070900@enterprisedb.com> <4E74D21C.2070503@enterprisedb.com> <4E7B1A7C.80103@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201110/159 X-Sequence-Number: 195965 On 22.09.2011 22:12, Alexander Korotkov wrote: > Patch without that dead code is attached. Thanks. Can you elaborate the consider-split algorithm? The criteria to select the new split over the previously selected one is this: > ! /* > ! * If ratio is acceptable, we should compare current split with > ! * previously selected one. If no split was selected then we select > ! * current anyway. Between splits of one dimension we search for > ! * minimal overlap (allowing negative values) and minimal ration > ! * (between same overlaps. We switch dimension if find less overlap > ! * (non-negative) or less range with same overlap. > ! */ > ! range = diminfo->upper - diminfo->lower; > ! overlap = ((leftUpper) - (rightLower)) / range; > ! if (context->first || > ! (context->dim == dimNum && > ! (overlap < context->overlap || > ! (overlap == context->overlap && ratio > context->ratio))) || > ! (context->dim != dimNum && > ! ((range > context->range && > ! non_negative(overlap) <= non_negative(context->overlap)) || > ! non_negative(overlap) < non_negative(context->overlap))) > ! ) > ! { Why are negative overlaps handled differently across dimensions and within the same dimension? Your considerSplit algorithm in the SYRCoSE 2011 paper doesn't seem to make that distinction. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com