From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | chris <cbbrowne(at)ca(dot)afilias(dot)info> |
Cc: | pgsql-hackers(at)postgresql(dot)org, JanWieck(at)Yahoo(dot)com |
Subject: | Re: Postgres-R: primary key patches |
Date: | 2008-07-19 15:54:51 |
Message-ID: | 48820E4B.9050603@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
chris wrote:
> You may want to have a chat with Jan; he's got some thoughts on a more
> general purpose mechanism that would be good for this as well as for
> (we think) extremely efficient bulk data loading.
Jan, mind to share your thoughts? What use cases for such a general
purpose mechanism do you see?
What I can imagine doing on top of Postgres-R is: splitting up the data
and feeding multiple backends with it. Unlike Postgres-R's internal use,
you'd still have to check the data against constraints, I think.
It would involve the origin backend asking for help from the manager.
That one checks for available helper backends and then serves as a
message dispatcher between the origin and helper backends (as it does
for replication purposes). Please note that it already uses shared
memory extensively, so the manager doesn't need to copy around the data
itself.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-19 16:39:34 | Re: Getting to universal binaries for Darwin |
Previous Message | Markus Wanner | 2008-07-19 15:52:34 | Re: Postgres-R: primary key patches |