Marten Feldtmann wrote:
>
> > >
> > > Therefore: for object system you need complete other types of object
> > > identification numbers.
> >
> > I agree, that's why I have suggested an implied super-class "Object" for
> > all postgresql objects. Then you could do "SELECT ** FROM object WHERE
> > oid=?". The ability to place an index over sub-class hierarchies (in
> > this case oid for all objects) would get the good performance.
>
> I can not believe, that this will result in a good performance. This
> column (object identifier) would need an index to cover ALL objects
> ... and this index will be growing and now image a system with about
> 1.000.000 objects and now try to insert a new object. Indices on such
> large mount of value maybe a problem.
>
> On the other hand: the solution you mentioned can be done without an
> implied table - which would be a special solution. The application can
> create the "super"-table and should be responsible for it.
The implied table doesn't do anything to performance. Having an index on
that table obviously needs to be maintained and the decision to create
such an index would be by the user. So the user can make use of such an
implied super-table or not as they please. But having such a global
index is necessary for an ODBMS, and I can tell you that for the Versant
ODBMS it is lightning fast even with gigabytes of data (I have seen
Versant grown to 100 Gig). Versant does use an indexing mechanism.
> Have you ever create a 1:n association with about 800 entries ?
In postgres, no. In other ODBMS, yes easily.
> Actually I do not know, how many entries such an array may
> have. Unlimited ?
To work properly we do need TOAST so that tuples can grow bigger.
> How do I remove an entry, how do I delete an
> entry. I may have a closer look at that.
Adding and deleting entries would be done in memory and then the
attribute updated in one go. Of course with an ODBMS you can create more
sophisticated data structures if you need really huge arrays, like roll
your own btree, or whatever thing you can find in Knuth.