From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig James <cjames@emolecules.com>
cc: Janek Sendrowski <janek12@web.de>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: ORDER BY using index, tsearch2
In-reply-to: 
 <CAFwQ8rc=R=S3RFZzQkGjNgYpQQHQcyA9NAw+aU45SK-mniKPMg@mail.gmail.com>
References: 
 <trinity-c65fe076-4523-4971-999c-367286014ca9-1386800970193@3capp-webde-bs11>
 <CAFwQ8rc=R=S3RFZzQkGjNgYpQQHQcyA9NAw+aU45SK-mniKPMg@mail.gmail.com>
Comments: In-reply-to Craig James <cjames@emolecules.com>
 message dated "Wed, 11 Dec 2013 15:38:09 -0800"
Date: Wed, 11 Dec 2013 18:55:57 -0500
Message-ID: <17031.1386806157@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Craig James <cjames@emolecules.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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance