On Sat, 17 May 2008, Marko Kreen wrote:
On 5/17/08, Steve Singer <[EMAIL PROTECTED]> wrote:
Somewhat unrelated, I can see use-cases for replacing the call to random()
with something that allows user defined polices for RUN ON ANY.
Well, thats why the RUN ON userfunc(..); exists. Also notice the function
can tag more that one partition for execution.
Or did you mean something else than partition selection by "user
defined policy"?
I see RUN ON userfunc() as being for partitioning where the correctness
requires that the query be run on the result of userfunc. I see RUN ON ANY
as being for load-balancing. You might want to RUN ON ANY with a round
robin balancing, or maybe consider the load of servers for doing the
balancing.
In the case of RUN ON ANY it seems that the database the query gets sent
to doesn't matter. It might make sense for plproxy to try the next database
if it can't connect to the first one it picks. You wouldn't want this for
partitioning queries. If plproxy knows if you mean 'the query has to be run
on these partitions' versus 'run the query on any partition, using method x
to choose' then that type of things would be possible.
Steve
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
