Message-ID: <4358BB78.5050303@sigaev.ru>
Date: Fri, 21 Oct 2005 13:57:12 +0400
From: Teodor Sigaev <teodor@sigaev.ru>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US;
 rv:1.7.12) Gecko/20050927
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Fuhr <mike@fuhr.org>, pgsql-docs@postgresql.org,
	Oleg Bartunov <oleg@sai.msu.su>
Subject: Re: Multicolumn index doc out of date?
References: <20050912142647.GA34685@winnie.fuhr.org>
	<23966.1126553464@sss.pgh.pa.us> <4326BBF5.4090900@sigaev.ru>
	<15864.1129854901@sss.pgh.pa.us>
In-Reply-To: <15864.1129854901@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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/