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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
