Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> Then someone said all the code was going to be discarded anyway and the
> protocol moved to Corba. That threw a spanner in the works and I havn't
> done anything since because I couldn't get any more details.
There's been some talk of using Corba, but it's certainly not a done
deal; in fact I don't think anyone's actively working on it right now.
> So here's the question again. Is Corba really a good thing for a
> database, seeing as a db is concerned with transferring massive chunks
> of simply formatted data. I'm no Corba guru, but I would have thought
> (a) Corba would be not very efficient at that sort of thing, probably
> adding big overhead in bytes, and possibly a lot more protocol back
> and forth, and (b) isn't the protocol simple enough anyway that Corba
> is overkill.
The attraction of Corba to my mind is that it might save us from the
convert-everything-to-text bottleneck of the current protocol (by
providing cross-platform byte order translation and so forth). That
should give us a performance boost, hopefully more than enough to cancel
out any added overhead. I won't be very excited about switching to
Corba if it turns out to be a performance dog compared to what we have.
I'm not a Corba guru (at the moment anyway...) so someone else might be
able to offer a more-informed opinion here.
The alternative is to stick with the present protocol and perhaps try
to sandpaper off some of its uglier corners. It'd probably be worth
discussing what we might want in that direction, if only so we can get
a feel for how much work would be involved if we go that route rather
than the Corba route.
(Or we could do neither, instead inventing a brand-new protocol that's
still Postgres-only, but that seems like it has no particular
attraction... there's a lot of work invested in the current frontends
and if we're going to throw it away we probably ought to adopt a
standards-based protocol. IMHO anyway.)
regards, tom lane