From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | chris(at)bitmead(dot)com, Marten Feldtmann <marten(at)feki(dot)toppoint(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, chris(at)bitmead(dot)com, pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |
Date: | 2000-02-04 05:17:10 |
Message-ID: | 3.0.1.32.20000203211710.00fd09c0@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers pgsql-sql |
At 02:42 PM 2/4/00 +1100, Chris Bitmead wrote:
>Not true, because if the wrapper conforms to the ODMG standard, it will
>be compatible with ObjectStore, Versant, the new Sun RDBS standard,
>Gemstone, and many others.
Without prejudice, I'd be interested in some order-of-magnitude
market share for these technologies vs., say, Oracle.
>The biggest thing you can do for speed is to have less objects/tuples
>in the database. Inheritance and the array feature of postgresql
>can improve things here by orders of magnitude.
There's no doubt of this, for applications that can make use
of the paradigms.
>The problem is that
>these
>two features are not viable to use at present. With an ODMG interface,
>and TOAST to allow tuples of unlimited size this will then be a viable
>feature. In some situations this will improve queries by 100x even
>with the most brain-dead optimizer. ODBMS doesn't care a great deal
>about wonderful optimizers because joins are less necessary.
And this last statement I really have to wonder about. For restricted
application spaces, yeah, no doubt. But in general, no way.
>Exactly, so stop mapping things and creating complicated joins. ODBMSes
>do not do ANY joins to re-create objects. That's why mappers suck so
>hard.
If they don't do joins, then presumably they map many-to-one relations
by copying data into each of the "many" table rows. TANSTAAFL, no?
Though this strategy is a very viable one in today's big-memory, big-disk
environment. It's not clear to me that a extremely smart RDBMS system
couldn't decide to add redundancy itself and gain much of the efficiency,
but, heck, that's just my weak, uncreative compiler-writer mind at work
again.
(and clearly, of course, PG isn't on any threshold of doing it, I'm
thinking in theoretical space here).
>Now with an ODBMS, a Car with 4 wheels and a steering wheel we'll have 6
>objects in the database - 1 Car, 4 RoadWheels and 1 SteeringWheel. With
>a relational mapper, depending on how you map it you'll have 21 objects
>- 5 CarPart objects, 5 wheel objects, 4 road wheel, 1 steering wheel, 1
>car and 5 car_carpart relation entities. And when you join it all
>together you'll have to join against 6 tables instead of 3.
Not really. You'd probably denormalize and not worry about it, in
practice.
Would the result be as beautiful? I don't know - do most car designers
think that SteeringMechanism and PavementInterface are the same? It's
true for a variety of reasons in today's cars that aren't actually
related, and high-end race cars are exploring joystick control.
So one could claim that your hierarchy is merely limiting creative
expression...
- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From | Date | Subject | |
---|---|---|---|
Next Message | mathprof | 2000-02-04 05:50:59 | DefineQueryRewrite: rule plan string too big-- workaround? |
Previous Message | Chris Bitmead | 2000-02-04 03:42:00 | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-04 05:26:00 | Re: [HACKERS] Another nasty cache problem |
Previous Message | Chris Bitmead | 2000-02-04 05:16:43 | Time travel |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-04 06:48:21 | Re: [SQL] Install: Undefined symbol `_TAS' |
Previous Message | Chris Bitmead | 2000-02-04 03:42:00 | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |