On Wed, 2007-04-04 at 12:10 -0700, Joshua D. Drake wrote:
> Simon Riggs wrote:
> > On Wed, 2007-04-04 at 20:55 +0200, Markus Schiltknecht wrote:
> >
> >> Questioning the other way around: do we need any sort of multi-table
> >> indexes at all, or isn't it enough to teach the planner and executor how
> >> to intelligently scan through (possibly) multiple indexes to get what is
> >> requested?
> >
> > No, I don't think we need multi-table indexes at all.
>
> If we don't have multi-table indexes how do we enforce a primary key
> against a partitioned set? What about non primary keys that are just
> UNIQUE? What about check constraints that aren't apart of the exclusion?
What I've been saying is that there is a way to do this that avoids the
need for multi-table indexes (MTIs), see earlier discussion. That way
avoids the massive performance overheads of MTIs, and also covers most
use-cases I can personally imagine.
I can come up with arbitrary examples that require them, but I've not
seen one that makes sense in a real business app. Calling columns a, b
and c disguises the validity of the example, IMHO.
I'm not against someone else writing them and I'm sure its a great
intellectual challenge, but I doubt whether it is worth the trouble
anytime soon because the real range of uses for them is not that wide.
Sure, Oracle has them, but in my view they are welcome to them too.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com