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 12260.1146157091@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN - Generalized Inverted iNdex. Try 3.  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: GIN - Generalized Inverted iNdex. Try 3.
Re: GIN - Generalized Inverted iNdex. Try 3.
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ANSI-strict pointer aliasing rules
Next
From: Taral
Date:
Subject: Re: ANSI-strict pointer aliasing rules