Re: [PATCHES] Bitmapscan changes
От | Hannu Krosing |
---|---|
Тема | Re: [PATCHES] Bitmapscan changes |
Дата | |
Msg-id | 1173884379.3270.3.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [PATCHES] Bitmapscan changes (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: [PATCHES] Bitmapscan changes
Re: [PATCHES] Bitmapscan changes |
Список | pgsql-hackers |
Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki Linnakangas: > Tom Lane wrote: > > At this point I'm feeling unconvinced that we want it at all. It's > > sounding like a large increase in complexity (both implementation-wise > > and in terms of API ugliness) for a fairly narrow use-case --- just how > > much territory is going to be left for this between HOT and bitmap indexes? > > I'm in a awkward situation right now. I've done my best to describe the > use cases for clustered indexes. ... > Just to recap the general idea: reduce index size taking advantage of > clustering in the heap. > > Clustered indexes have roughly the same performance effect and use cases > as clustered indexes on MS SQL Server, and Index-Organized-Tables on > Oracle, but the way I've implemented them is significantly different. On > other DBMSs, the index and heap are combined to a single b-tree > structure. The way I've implemented them is less invasive, there's no > changes to the heap for example, and it doesn't require moving live tuples. Do you keep visibility info in the index ? How does this info get updated when visibility data changes in the heap ? If there is no visibility data in index, then I can't see, how it gets the same performance effect as Index-Organized-Tables, as lot of random heap access is still needed. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
В списке pgsql-hackers по дате отправления: