Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 38615B5DBD9 for ; Sun, 2 Oct 2011 20:21:58 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 32385-09 for ; Sun, 2 Oct 2011 23:21:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 1E16CB5DBD8 for ; Sun, 2 Oct 2011 20:21:50 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p92NLnZL003232; Sun, 2 Oct 2011 19:21:49 -0400 (EDT) To: Heikki Linnakangas cc: Oleg Bartunov , Pgsql Hackers Subject: Re: WIP: SP-GiST, Space-Partitioned GiST In-reply-to: <4E7B086D.5050602@enterprisedb.com> References: <4E7B086D.5050602@enterprisedb.com> Comments: In-reply-to Heikki Linnakangas message dated "Thu, 22 Sep 2011 13:05:33 +0300" Date: Sun, 02 Oct 2011 19:21:48 -0400 Message-ID: <3231.1317597708@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201110/47 X-Sequence-Number: 195853 Heikki Linnakangas writes: > On 06.09.2011 20:34, Oleg Bartunov wrote: >> Here is the latest spgist patch, which has all planned features as well as >> all overhead, introduced by concurrency and recovery, so performance >> measurement should be realistic now. > I'm ignoring the text suffix-tree part of this for now, because of the > issue with non-C locales that Alexander pointer out. It seems to me that SP-GiST simply cannot work for full text comparisons in non-C locales, because it's critically dependent on the assumption that comparisons of strings are consistent with comparisons of prefixes of those strings ... an assumption that's just plain false for most non-C locales. We can dodge that problem in the same way that we did in the btree pattern_ops opclasses, namely implement the opclass only for the = operator and the special operators ~<~ etc. I think I favor doing this for the first round, because it's a simple matter of removing code that's currently present in the patch. Even with only = support the opclass would be extremely useful. Something we could consider later is a way to use the index for the regular text comparison operators (< etc), but only when the operator is using C collation. This is not so much a matter for the index implementation as it is about teaching the planner to optionally consider collation when matching an operator call to the index. It's probably going to tie into the unfinished business of marking which operators are collation sensitive and which are not. In other news, I looked at the patch briefly, but I don't think I want to review it fully without some documentation. The absolute minimum requirement IMO is documentation comparable to what we have for GIN, ie a specification for the support methods and some indication of when you'd use this index type in preference to others. I'd be willing to help copy-edit and SGML-ize such documentation, but I do not care to reverse-engineer it from the code. regards, tom lane