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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, 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-27 16:58:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Teodor Sigaev wrote:
>> We appreciate any comments, help and suggestions. For third item we haven't 
>> idea how fix it except to exclude GIN index from check.

> How about adding a column to pg_am indicating "these indexes must always
> keep same tuple count as heap".  This would be true for all current AMs,
> false for GIN.

There's a definitional issue here, which is what does it mean to be
counting index tuples.  I think GIN could bypass the VACUUM error check
by always returning the heap tuple count as its index tuple count.  This
would result in the index's reltuples field getting set to that value
rather than the number of index entries, but arguably that's what we
want anyway.  From what I recollect of the planner's use of index
reltuples, values greater than heap tuple count would not behave sanely:
it considers index.reltuples to be an upper bound on the number of rows
an indexscan could fetch.

The ideal thing would be for GIN to return a count of the number of
distinct heap tuples referenced by the entries in the index, but I
suppose that would be impractical for VACUUM to compute.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: TaralDate: 2006-04-27 17:04:45
Subject: Re: ANSI-strict pointer aliasing rules
Previous:From: Tom LaneDate: 2006-04-27 16:50:10
Subject: Re: ANSI-strict pointer aliasing rules

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