Re: GIN - Generalized Inverted iNdex. Try 3. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GIN - Generalized Inverted iNdex. Try 3.
Date
Msg-id 588.1146233649@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN - Generalized Inverted iNdex. Try 3.  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN - Generalized Inverted iNdex. Try 3.  (Martijn van Oosterhout <kleptog@svana.org>)
Re: GIN - Generalized Inverted iNdex. Try 3.  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.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


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.
Next
From: Martijn van Oosterhout
Date:
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.