From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Oleg Bartunov <oleg@sai.msu.su>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
Date: Sun, 02 Oct 2011 19:21:48 -0400
Message-ID: <3231.1317597708@sss.pgh.pa.us> (raw)
In-Reply-To: <4E7B086D.5050602@enterprisedb.com>
References: <Pine.LNX.4.64.1108312241050.26195@sn.sai.msu.ru>
<Pine.LNX.4.64.1109011608160.26195@sn.sai.msu.ru>
<Pine.LNX.4.64.1109030053330.26195@sn.sai.msu.ru>
<Pine.LNX.4.64.1109062127330.26195@sn.sai.msu.ru>
<4E7B086D.5050602@enterprisedb.com>
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, heikki.linnakangas@enterprisedb.com, oleg@sai.msu.su
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
In-Reply-To: <3231.1317597708@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox