Re: [HACKERS] Priorities for 6.6

Hannu Krosing <hannu(at)trust(dot)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