Re: [GENERAL] Re: Postgresql OO Patch

From: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
To: Marten Feldtmann <marten(at)feki(dot)toppoint(dot)de>
Cc: "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres Hackers List <hackers(at)postgresql(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Re: Postgresql OO Patch
Date: 2000-05-24 06:27:18
Message-ID: 392B7646.994F46E5@nimrod.itg.telecom.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Oskar Bartenstein 2000-05-24 06:33:27 Re: Where is the JDBC Driver for PostgreSQL on Redhat6.0?
Previous Message Michael Meskes 2000-05-24 06:06:27 Re: SQL Recursion

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2000-05-24 09:10:58 yowch: dumpRules(): SELECT failed for table website.
Previous Message Bruce Momjian 2000-05-24 05:09:36 Re: setproctitle()