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: Taral||Date: 2006-04-27 17:04:45|
|Subject: Re: ANSI-strict pointer aliasing rules|
|Previous:||From: Tom Lane||Date: 2006-04-27 16:50:10|
|Subject: Re: ANSI-strict pointer aliasing rules |