Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZIB4R-00044Z-At for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jul 2015 07:37:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZIB4Q-0006zp-HJ for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jul 2015 07:37:34 +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 1ZIB39-0005US-IU for pgsql-hackers@postgresql.org; Thu, 23 Jul 2015 07:36:15 +0000 Received: from mail-wi0-x243.google.com ([2a00:1450:400c:c05::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZIB31-0000hw-LF for pgsql-hackers@postgresql.org; Thu, 23 Jul 2015 07:36:14 +0000 Received: by wilh8 with SMTP id h8so25676483wil.3 for ; Thu, 23 Jul 2015 00:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6ouP1zflmUq/QOuIAJY0kjs4xMyQ2TrnW9H/R6wo4vA=; b=HR4TAT/HpXvSY6G5hCbniMV8eQARs5L074fRx/hDEXkA/u0rOPQwjNmgbn2BmJh4+8 Cb01d8C4vRb4Yt3VNs015rXNaCEaZSj2ctOSF4PdchQPyvegtzZOaJ10xRGbEkVCj22N jarmSCtmzlQGxWE1J8j4YhBlpnqAms/o1lirtgrXVpQt5wnRPCKvukaRB9gtpkNU0BnX xSVkLKOBTDb5vqzHlxNtQoUnbcwDk0ZUHYQ6q3hHfKM3buueoO7aQ9P+qjzmUN6rwJXK UbKWLL3fOrCjBn587YkMdLGDyFx4b6c3S5aQjtQ6tTFv6GbeMnTaePt1guq/KKD3sHJY 9uIA== X-Received: by 10.194.123.4 with SMTP id lw4mr12537350wjb.94.1437636966083; Thu, 23 Jul 2015 00:36:06 -0700 (PDT) Received: from [192.168.1.105] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by smtp.gmail.com with ESMTPSA id ju2sm7111895wid.12.2015.07.23.00.36.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 00:36:05 -0700 (PDT) Message-ID: <55B09964.80707@iki.fi> Date: Thu, 23 Jul 2015 10:36:04 +0300 From: Heikki Linnakangas Reply-To: hlinnaka@iki.fi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Paul Ramsey CC: Teodor Sigaev , Pgsql Hackers Subject: Re: compress method for spgist - 2 References: <54907069.1030506@sigaev.ru> <54993A76.7050308@vmware.com> <54DE237E.4000207@sigaev.ru> <54EDD887.8030703@vmware.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.4 (--) 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 03/04/2015 06:58 PM, Paul Ramsey wrote: > On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas > wrote: >> In the original post on this, you mentioned that the PostGIS guys planned to >> use this to store polygons, as bounding boxes >> (http://www.postgresql.org/message-id/5447B3FF.2080406@sigaev.ru). Any idea >> how would that work? > > Poorly, by hanging boxes that straddled dividing lines off the parent > node in a big linear list. The hope would be that the case was > sufficiently rare compared to the overall volume of data, to not be an > issue. Oddly enough this big hammer has worked in other > implementations at least passable well > (https://github.com/mapserver/mapserver/blob/branch-7-0/maptree.c#L261) Ok, I see, but that's not really what I was wondering. My question is this: SP-GiST partitions the space into non-overlapping sections. How can you store polygons - which can overlap - in an SP-GiST index? And how does the compress method help with that? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers