Skip site navigation (1) Skip section navigation (2)

Re: GIN - Generalized Inverted iNdex. Try 3.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Christopher Kings-Lynne <chris(dot)kings-lynne(at)calorieking(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.
Date: 2006-04-28 14:14:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-04-28 14:28:04
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.
Previous:From: Teodor SigaevDate: 2006-04-28 13:41:18
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group