Craig James <cjames@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
