Re: GIN - Generalized Inverted iNdex. Try 3.

Teodor Sigaev <teodor(at)sigaev(dot)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