Hiroshi Inoue schrieb:
>
> Chris wrote:
>
> > It's pretty clear to me that an inherited index should be only one
> > index. There may be a case for optional non-inherited indexes (CREATE
> > INDEX ON ONLY foobar), but if the index is inherited, it is just one
> > index.
> >
> > At the end of the day though, the reason is only performance. The
> > semantics should be the same no matter whether implemented as multiple
> > indexes or not. Performance is much better with one index though.(*)
> >
>
> Is it true ?
> How to guarantee the uniqueness using multiple indexes ?
>
Sorry to say, but you all should really think about, what inheritance
should mean !!!!
In the classic mapping strategy (OO-rdbms mapping) it's said, that
each class is mapped to ONE table ! This is the classic mapping
strategy, which is mentioned in every literature.
The point is: this is classic, but noone does it like this if
your really have a larger hierarchy of classes. You'll not get
any good performance, when solving an association in your oo
program, because the framework has to query against each
table: 6 tables - 6 queries !!! :-(((((
With the PostgreSQL approach one can send ONE query against
the tables and one would get one result ... which will be
much faster (I hope so ... that has to be prooved ..).
--
I'm not sure, that inherited indices should be really ONE
index. There are very well reasons NOT to build ONE larger
index.
Actually one should think about: why do I really want to
have inheritance in the oo-rdbms ? Actually I could put
all columns (of all classes in this hierarchy into one table
and that's it). I would like to have inheritance in this
database system, because the tables are getting smaller
and queries against special classes (eh tables) are becoming
faster.
Actually the inserts will be much faster also because you
have several smaller indices.
I've run tests here with ONE large table (5 columns and
5 indices) holding data for about 17 classes and the result
is: the insert/update path is the problem and not the
select-path. insert-performance is decreasing in a
linear fashon ... very, very bad.
Marten