Re: GIN - Generalized Inverted iNdex. Try 3.

Teodor Sigaev <teodor@sigaev.ru> writes:
>> 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?

Oh, I was thinking of having VACUUM put the heap tuple count into the
struct and then amvacuumcleanup could copy it over to the index tuple
count.  A "skipcheck" flag only solves the cosmetic problem of not
getting the warning, it doesn't fix things so that the correct count
ends up in the index's reltuples entry.

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

OK, in that case we'd better add a real amclusterable flag to pg_am,
rather than assuming amorderstrategy can be used to decide.

> So, two columns about clustering?
> amclustered
> amclusterable

Huh?  Why two?  Either you are allowed to cluster on indexes of this
type, or you're not.  I don't see the point of any other distinction.
        regards, tom lane