Re: [HACKERS] CFH: Mariposa, distributed DB

Поиск
Список
Период
Сортировка
От Don Baccus
Тема Re: [HACKERS] CFH: Mariposa, distributed DB
Дата
Msg-id 3.0.1.32.20000207151801.010a6a90@mail.pacifier.com
обсуждение исходный текст
Ответ на Re: [HACKERS] CFH: Mariposa, distributed DB  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
Ответы Re: [HACKERS] CFH: Mariposa, distributed DB  (Karel Zak - Zakkr <zakkr@zf.jcu.cz>)
Список 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@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] ONLY
Следующее
От: Vince Vielhaber
Дата:
Сообщение: Re: [HACKERS] New Globe