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
