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

> 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:

1) true OO semantics are difficult/impossible to accomplish with SQL.
This is one reason why Postgres is probably in the OR realm rather than
true OO.

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! :)

3) Indices are fundamentally present to speed up access, though we use
them for other purposes too (such as enforcing uniqueness). Perhaps the
topic of inheritance, uniqueness, and referential integrity (foreign
keys, etc) should be solved (or at least discussed) independent of
indices, though indices or index-like structures may be involved in the
solution.

4) imho, the roughest areas of existing (or missing) capability in
Postgres involve array types and types which require additional support
information (such as exact numerics). Focusing on fixing/improving these
areas may lead to cleaning up semantics, mechanisms, and capabilities in
the backend, and make other (more derived?) features such as constraint
inheritance and enforcement easier to implement. Well, it will help
something anyway, even if not constraints :)

- Tom