Re: GIN - Generalized Inverted iNdex. Try 3.

> We could probably fix that by adding it to the stats structs that are
> passed around during VACUUM.  I'd rather not hardwire a GIN special case
> in vacuum.c as per your "quick hack".

ok.   amskipcheck?

> Here I think it would be best to add an indclusterable column to pg_am.
GIN is _always_ clustered, it returns pointers to heap in ascending order.

> Actually, does clustering on *any* current index type except btree make
> sense?  None of them have semantically interesting index ordering
I don't know about hash index, but for GiST clustering can speed up query's 
execution.

As I understand your point, cluster on btree very useful on range searches ( 
BETWEEN clause ), but don't significantly speeds up queries with OR ( id=1 or 
id=500000 or id=6000000 ). Several GiST's opclasses has similar behaviour:
* ltree with queries to search descendant of node. ltree uses B-tree like  structure
* R-tree - contains operation

In any case, clustering can prevent from chaotic seeks on disk.

So, two columns about clustering?
amclustered
amclusterable


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/