Re: [HACKERS] On improving OO support in posgresql and relaxing oid bottleneck at the same time

Maurice Gittens>
> >> I'm currently under the impression that the following change in the
> >> postgresql system would benefict the overall performance and quality
> >> of the system.
> >>
> >> Tuples for a class and all it's derived classes stored in one file.
> >
> >I hate to sound like a "small thinker" here, but I'd be concerned about
> >some issues:
> >
...
> >2) Supporting inheritance using one-file storage probably leads to
> >larger overhead in _all_ file accesses, not just ones containing
> >inherited tables. Tuples would now contain a variable number of fields,
> >with variable definitions, with ... Ack! :)
>
> Yes but this overhead is very small for tables without inheritance.
> An extra statement like:

Anything that gets done for every row is on _the_ critical path. Any extra
code here will have a performance penalty. We are already an order of
magnitude too slow on scans. Think in terms of a few hundred instructions
per row.

I will also say that table inheritance is rarely used in real applications.
Partly no doubt this is because the implementation is not wonderful, but
I also think that it may be one of those ideas like time travel that
sound great but in practice noone can figure out a use for it.

> heap_getnext(ScanDesc scanDesc)
> {
> ...
> while(!done)
> {
> tuple = readTuple(...)
> ...
> if (IsInstanceOf(tuple -> reloid, scanDesc -> reloid)
> {
> return tuple;
> }
> ...
> }
>
> The information on inheritance relations between classes can be precomputed
> when a heap scandesc is created.
>
> This IMO this overhead is not significant, when there is no inheritance.
> When there is inheritance we simple use indices to speed things up,
> if it's deemed necesary.

I disagree, all per row overhead is significant. The primary operation in
the system is sifting rows.

But this is just the start of the extra overhead. What about the expression
evaluator trying to determine if this tuple matchs the where clause. Now it
has to determine column offset and type and "Equal" function etc for
each row.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.