| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Subject: | Re: spgist text_ops and LIKE |
| Date: | 2012-02-02 19:02:05 |
| Message-ID: | 27649.1328209325@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2012-02-02 19:07:21 | Re: spgist text_ops and LIKE |
| Previous Message | Duncan Rance | 2012-02-02 18:28:12 | Re: BUG #6425: Bus error in slot_deform_tuple |