| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig James <cjames(at)emolecules(dot)com> |
| Cc: | Janek Sendrowski <janek12(at)web(dot)de>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: ORDER BY using index, tsearch2 |
| Date: | 2013-12-11 23:55:57 |
| Message-ID: | 17031.1386806157@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Craig James <cjames(at)emolecules(dot)com> writes:
> A GIST is a tree, but there's no notion of ">" or "<", only yes/no at each
> tree branch. In this regard a GIST index is more like a hash table. You
> can't use a hash table to sort. It doesn't make sense.
Recent versions of PG do allow GIST indexes to be used to satisfy
K-nearest-neighbor queries, if the operator class supports that.
(This requires that the tree partitioning be done on some notion of
distance, and even then there'll be some traversal of irrelevant index
entries; but it way beats a full-table scan, or even full-index scan.)
But I'm not entirely sure if that's what the OP is asking about.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Janek Sendrowski | 2013-12-12 01:00:38 | Re: ORDER BY using index, tsearch2 |
| Previous Message | Craig James | 2013-12-11 23:38:09 | Re: ORDER BY using index, tsearch2 |