Bruce Momjian wrote:
>
> > This is a Call For Hackers:
> >
> > Some time ago, I floated a little discussion on this list about doing
> > some distributed database work with PostgreSQL. The project got back
> > burnered at work, but now has a timeline for needing a solution "this
> > summer." Recent discussions on this list about Postgres's historical
> > object roots got me back to the Berkeley db sites, and reminded me about
> > Mariposa, which is Stonebraker's take on distributed DBs.
> >
> > http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/
It has a nice concept of simulating free market for distributed query
optimisation. Auctions, brokers and all ...
>
> I have looked at the code. I have files that show all the diffs they
> made to it and they have some new files. It was hard for me to see what
> they were doing. Looks like they hacked up the executor and put in some
> translation layer to talk to some databroker.
The broker was for determining where to get the data from - as each table
could be queried from several sites there had to be a mechanism for the
planner to figure out the cheapest (or fastest if "money" was not a problem)
> It seems like an awfully
> complicated way to do it. I would not bother getting it to run, but
> figure out what they were trying to do, and why, and see how we can
> implement it. My guess is that they had one central server for each
> table, and you went to that server to get information.
They would not have needed the broker for such a simple scheme
IIRC they had no central table, but they doubled the length of oid and
made it to include the site id of the site that created the tuple.
It could be that they restricted changing a tuple to that site ?
The site to go for information was determined by an auction where each site
offered speed and cost for looking up the data. Usually the didn't also
quarantee the latest data, just the "best effort".
-------------------
Hannu
