Re: [HACKERS] Mariposa

> It strikes me as a bit odd to optimize the plan for a single site,
> then break it all apart again. My thoughts on this are to implement
> a two new node types: one a remote table, and one which represents
> access to a remote table. Remote tables have host info in them, and
> always be added to the plan with a remote-access node directly above
> them. Remote-access nodes would be seperate from their remote-table,
> to allow the communications cost to be slid up the plan tree, and merged
> with other remote-access nodes talking to the same server. This should
> maintain the order-agnostic nature of the optimizer. The executor will
> need to build SQL statements and from the sub-plans and submit them via
> standard network db access client librarys.
>
> First step, create a remote-table node, and teach the excutor how to get
> info from it. Later, add the seperable remote-access node.
>
> How insane does this sound now? Am I still a mad scientist? (...always!)

Sounds interesting, and doable. People have asked from time to time
about this. Our access routines are very modular, so if you can get
your stuff working inside the tuple access routines, you will have it
made. The easiest way may be to just hack up the storage manager
(smgr). Create a new access method, and hook your remote stuff to that.

You could try something easy like common backend NFS with some locking
protocol to prevent contension. In fact, NFS would be transparent
except for locking issues.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026