Tom Lane wrote:
> [ getting back to this documentation issue finally ]
>
> Teodor Sigaev <teodor@sigaev.ru> writes:
>
>>I disagree with last affirmation: inner pages of index contains fair union of
>>keys and enough helpful to select. Mailware ( http://www.pgsql.ru/db/mw )
>>sucsessfully use combined GiST index (date, tsvector) for searching.
>
>
>>GiST's split algorithm is good for unique leading keys, not so bad for small
>>number of non-unique values and bad for all equals leading key. But "bad" means
>>that itsn't optimal as picksplit for other keys may be. If there is several keys
>>which can be moved on left or right page without changing union of first key for
>>each page then GiST try put its on page (left or right) with smallest penalty
>>calculated by other keys. This algorithm is very similar to defining page to put
>>tuple with normal processing (without page split).
>
>
>>With unique leading key GiST's split is fully similar to BTree - it looks only
>>at leading key, but gistchoose isn't. Gistchoose (gistutil.c:622) chooses child
>>with smallest penalty and it looks to other keys if several leading keys has the
>>same penalty. In a GiST tree different keys may have the same penalty value with
>>new key.
>
>
> OK, how about this text then?
>
> A multicolumn GiST index can only be used when there is a query condition
> on its leading column. Conditions on additional columns restrict the
> entries returned by the index, but the condition on the first column is the
> most important one for determining how much of the index needs to be
> scanned. A GiST index will be relatively ineffective if its first column
> has only a few distinct values, even if there are many distinct values in
> additional columns.
Ok, I think.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
