Re: Multicolumn index doc out of date?
От | Oleg Bartunov |
---|---|
Тема | Re: Multicolumn index doc out of date? |
Дата | |
Msg-id | Pine.GSO.4.63.0510211839000.23078@ra.sai.msu.su обсуждение исходный текст |
Ответ на | Re: Multicolumn index doc out of date? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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@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. > > 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@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
В списке pgsql-docs по дате отправления: