Re: [HACKERS] Priorities for 6.6

Hannu Krosing <hannu@trust.ee> writes:
> E. to make 2. and B., C, D. possible, some more fundamental changes in
>    fe/be-protocol may be needed. There seems to be some effort for a new
>    fe/be communications mechanism using CORBA. 
>    But my proposal would be to adopt the X11 protocol which is quite
>    light but still very clean, well understood and which can transfer
>    arbitrary data in an efficient way.

... but no one uses it for database work.  If we're going to go to the
trouble of overhauling the fe/be protocol, I think we should adopt
something fairly standard, and that seems to mean CORBA.

> F. As a lousy alternative to 1. fix the LO storage. Currently _all_ of
>    the LO files are kept in the same directory as the tables and
>    indexes. this can bog down the whole database quite fast

Yes.  I was thinking last night that there's no good reason not to
just stick all the LOs into a single relation --- or actually two
relations, one having a row per LO (which would really just act to tell
you what LOs exist, and perhaps store access-privileges info) and one
that has a row per LO chunk, with columns LONumber, Offset, Data rather
than just Offset and Data as is done now.  The existing index on Offset
would be replaced by a multi-index on LONumber and Offset.  In this
scheme the LONumbers need not be tied hard-and-fast to OIDs, but could
actually be anything you wanted, which would be much nicer for
dump/reload purposes.

However, I am loathe to put *any* work into improving LOs, since I think
the right answer is to get rid of the need for the durn things by
eliminating the size restrictions on regular tuples.
        regards, tom lane