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: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
