| From: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
|---|---|
| To: | "Marko Kreen" <markokr(at)gmail(dot)com> |
| Cc: | "Chris Browne" <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Federated Postgresql architecture ? |
| Date: | 2008-06-30 13:34:27 |
| Message-ID: | 36e682920806300634y10a34fc1vfa9b18658d8e857b@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Jun 30, 2008 at 9:16 AM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> But I want to clarify it's goal - it is not to run "pre-determined
> queries." It is to run "pre-determined complex transactions."
Yes.
> And to make those work in a "federated database" takes huge amount
> of complexity that PL/Proxy simply sidesteps. At the price of
> requiring function-based API. But as the function-based API has
> other advantages even without PL/Proxy, it seems fine tradeoff.
Agreed. PL/Proxy has its own set of advantages.
As usual, it really just depends on the application and its requirements.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cédric Villemain | 2008-06-30 13:54:08 | Re: A guide/tutorial to performance monitoring and tuning |
| Previous Message | Marko Kreen | 2008-06-30 13:16:26 | Re: Federated Postgresql architecture ? |