Leonardo F <m_lists(at)yahoo(dot)it> writes:
> I hoped that since people mostly (>95%?) use plain btree indexes,
> a patch that helped CLUSTER with using such indexes would be fine
> (at least at first...). I guess that a patch that deals with all other types of
> indexes would be way more complicated (not at the "planning" stage,
> but in the scan+sort phase)?
Well, the expression cases would be more likely to cost more if
implemented as a sort, but that doesn't mean that a sort couldn't be a
win. Besides, even if you blow off the expression case, what about
nulls first/last, nondefault opclasses, etc?
regards, tom lane