Re: GIN - Generalized Inverted iNdex. Try 3.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN - Generalized Inverted iNdex. Try 3.
Дата
Msg-id 12260.1146157091@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN - Generalized Inverted iNdex. Try 3.  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: GIN - Generalized Inverted iNdex. Try 3.  (Teodor Sigaev <teodor@sigaev.ru>)
Re: GIN - Generalized Inverted iNdex. Try 3.  (Teodor Sigaev <teodor@sigaev.ru>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ANSI-strict pointer aliasing rules
Следующее
От: Taral
Дата:
Сообщение: Re: ANSI-strict pointer aliasing rules