Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
> 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to