Re: [HACKERS] CFH: Mariposa, distributed DB

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] CFH: Mariposa, distributed DB
Date: 2000-02-07 23:18:01
Message-ID: 3.0.1.32.20000207151801.010a6a90@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 04:57 PM 2/7/00 -0600, Ross J. Reedstrom wrote:

>CREATE TABLE widgets (
> part_no int4,
> location char16,
> on_hand int4,
> on_order int4,
> commited int4
>) PARTITION ON LOCATION USING btchar16cmp;

Oracle's partitioning is fixed, in other words once you choose a
condition to split on, you can't change it. In other words, in
your example:

>Then, the table is filled with tuples, all containing locations of either
>'Miami' or 'New York'.

After splitting the table into ">'Miami'" and "<='Miami" fragments,
I've been told that you can't (say) change it to ">'Boston'" and
have the proper rows move automatically.

In practice, partioning is often used to split tables on dates. You
might want to partion off your old tax data at the 7-yr old mark, and
each year as you do your taxes move the oldest tax data in your
"recent taxes" table split off to your "older taxes" table.

Apparently, Informix is smart enough to do this for you.

Since a couple of the people associated with the project are Informix
people, do you have any idea if Mariposa is able to do this?

>
>SELECT * from widgets;
>
>works as expected.
>
>Later, this table is fragmented:
>
>SPLIT FRAGMENT widgets INTO widgets_mi, widgets_ny AT 'Miami';

In other words some sort of "update the two tables AT <some new criteria>"

Whatever the answer to my question, Mariposa certainly looks interesting.
It's functionality that folks who do data warehousing really need.

>Oh, BTW, yes that does put _two_ interpreted Tcl scripts on the execution
>path for every query. Wonder what _that'll_ do for execution time. However,
>it's like planning/optimization time, in that it's spent per query, rather
>than per tuple.

Probably not as bad as you think, if they're simple and short. Once
someone has this up and running and integrated with PostgreSQL and
robust and reliable we can measure it and change to something else if
necessary :)

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2000-02-07 23:25:35 Re: [HACKERS] New Globe
Previous Message Chris Bitmead 2000-02-07 23:17:08 Re: [HACKERS] ONLY