pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Hannu Krosing <hannu@tm.ee>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Date: Tue, 08 Feb 2000 00:04:52 +0200
Message-ID: <389F4184.C968145F@tm.ee> (raw)
References: <200002072123.QAA21093@candle.pha.pa.us>

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



view thread (10+ messages)  latest in thread

Message-ID: <389F4184.C968145F@tm.ee>
Permalink:  ../389F4184.C968145F@tm.ee/
Also on:    postgresql.org/message-id/389F4184.C968145F@tm.ee

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: hannu@tm.ee, pgman@candle.pha.pa.us, reedstrm@wallace.ece.rice.edu
  Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
  In-Reply-To: <389F4184.C968145F@tm.ee>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox