Re: GIN - Generalized Inverted iNdex. Try 3.

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> One problem: ambulkdelete hasn't any access to heap or heap's statistics
> (num_tuples in scan_index() and vacuum_index() in vacuum.c). So, ambulkdelete
> can't set stats->num_index_tuples equal to num_tuples.

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

> 2) add indisclustered=true for all GIN indexes by changes in
> UpdateIndexRelation() and mark_index_clustered(). The issue is:
> can table be clustered on several indexes now? Because GIN is always 'clustered'
> table can be clustered on several GIN index and one any other. Cluster command
> on GIN index should do nothing. May be, it will be cleaner to add indclustered
> column to pg_am.

Here I think it would be best to add an indclusterable column to pg_am.
Actually, does clustering on *any* current index type except btree make
sense? None of them have semantically interesting index ordering
AFAIR, so maybe we should just reject CLUSTER on all of 'em not only GIN.

regards, tom lane