Joshua D. Drake wrote:
Hackers et al... I was wondering if there are any outstanding issues that need to be resolved in terms of the clustered index/bitmap changes?
I have a todo list of smaller items for clustered indexes, but the main design issues at the moment are:
1. How to handle sorting tuples in a scan, or should we choose a design that doesn't require it?
Should we add support for sorting tuples in scans on the fly, which gives more space savings when there's updates, and would also be useful in the future to support binned bitmap indexes?
Or should we only form groups from tuples that are completely in order on page-level? That makes a clustered index to lose its space savings quicker, when tuples are updated. HOT reduces that affect, though. This approach would also reduce the CPU overhead of scans, because we could do binary searches within groups.
At the moment, I'm leaning towards the latter approach. What do others think?
2. Clustered indexes need the support for candidate-matches. That needs to be added to the amgetmulti and amgettuple interfaces. I've sent a patch for amgetmulti, and a proposal for the amgettuple.
3. Clustered index needs to reach out to the heap for some operations, like uniqueness checks do today, blurring the modularity between heap and index. Are we willing to live with that? Is there something we can do to make it less ugly?
I'd like to get some kind of confirmation first that 1 and 3 are not showstoppers, to avoid wasting time on a patch that'll just get rejected in the end, and then submit a patch for 2, and have that committed before the main patch.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
