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 15:05:45
Message-ID: 993.1146236745@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Teodor SigaevDate: 2006-04-28 15:44:36
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.
Previous:From: Teodor SigaevDate: 2006-04-28 14:44:51
Subject: Re: GIN - Generalized Inverted iNdex. Try 3.

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