Robert Haas <robertmh...@gmail.com> writes: > I'm having trouble figuring out under what set of circumstances spgist > is expected to be the best available alternative. It only supports a > small subset of the data types that GiST does, so I suppose the point > is that it should be faster for the cases that it does handle. And, > considering that this is all brand-new code, the fact that it's almost > keeping pace with btree on both pattern-matching and equality > comparisons is certainly respectable -- but I so far haven't found any > cases where it's a clear win. There's limited glory in being the > almost-fastest way of indexing for a certain class of queries. > Admittedly, I haven't tried the point-in-box stuff yet.
I think the text opclass is mostly meant as sample code/proof-of-concept. What spgist is likely to be good for is queries that btree can't cope with at all. But it's cute that we can make it handle LIKE for a few more lines of code, so I'm fine with adding that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers