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. I know the patch needs refactoring, I've refrained from making API changes and tried to keep all the ugliness inside the b-tree, knowing that there's changes to the indexam API coming from the bitmap index patch as well.
I've been seeking for comments on the design since November, knowing that this is a non-trivial change. I have not wanted to spend too much time polishing the patch, in case I need to rewrite it from scratch because of some major design flaw or because someone comes up with a much better idea.
It's frustrating to have the patch dismissed at this late stage on the grounds of "it's not worth it". As I said in February, I have the time to work on this, but if major changes are required to the current design, I need to know.
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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
