Skip site navigation (1) Skip section navigation (2)

Re: Multicolumn index doc out of date?

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Michael Fuhr <mike(at)fuhr(dot)org>,pgsql-docs(at)postgresql(dot)org
Subject: Re: Multicolumn index doc out of date?
Date: 2005-10-21 14:40:03
Message-ID: Pine.GSO.4.63.0510211839000.23078@ra.sai.msu.su (view raw or flat)
Thread:
Lists: pgsql-docs
btw, I think it's worth to add link to src/backend/access/gist/README
file, which we updated recently.

 	Oleg

On Thu, 20 Oct 2005, Tom Lane wrote:

> [ getting back to this documentation issue finally ]
>
> Teodor Sigaev <teodor(at)sigaev(dot)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.
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>

 	Regards,
 		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

pgsql-docs by date

Next:From: BobDate: 2005-10-21 18:06:05
Subject: Minor changed needed to doc on untrusted pl/perl example
Previous:From: Teodor SigaevDate: 2005-10-21 09:57:12
Subject: Re: Multicolumn index doc out of date?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group