> 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/