Re: Plans for solving the VACUUM problem
От | Bruce Momjian |
---|---|
Тема | Re: Plans for solving the VACUUM problem |
Дата | |
Msg-id | 200105181835.f4IIZK809193@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Plans for solving the VACUUM problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Plans for solving the VACUUM problem
|
Список | pgsql-hackers |
> Oleg Bartunov <oleg@sai.msu.su> writes: > > On Thu, 17 May 2001, Tom Lane wrote: > >> We will also want to look at upgrading the non-btree index types to allow > >> concurrent operations. > > > am I right you plan to work with GiST indexes as well ? > > We read a paper "Concurrency and Recovery in Generalized Search Trees" > > by Marcel Kornacker, C. Mohan, Joseph Hellerstein > > (http://citeseer.nj.nec.com/kornacker97concurrency.html) > > and probably we could go in this direction. Right now we're working > > on adding of multi-key support to GiST. > > Yes, GIST should be upgraded to do concurrency. But I have no objection > if you want to work on multi-key support first. > > My feeling is that a few releases from now we will have btree and GIST > as the preferred/well-supported index types. Hash and rtree might go > away altogether --- AFAICS they don't do anything that's not done as > well or better by btree or GIST, so what's the point of maintaining > them? We clearly have too many index types, and we are actively telling people not to use hash. And Oleg, don't you have a better version of GIST rtree than our native rtree? I certainly like streamlining our stuff. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: