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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/