From: | Steve Singer <ssinger_pg(at)sympatico(dot)ca> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [rfc,patch] PL/Proxy in core |
Date: | 2008-05-18 01:36:50 |
Message-ID: | BAYC1-PASMTP1593BA292B90A6EC638793ACCA0@CEZ.ICE |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 17 May 2008, Marko Kreen wrote:
> On 5/17/08, Steve Singer <ssinger_pg(at)sympatico(dot)ca> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-18 01:36:53 | Re: Link requirements creep |
Previous Message | Andrew Dunstan | 2008-05-18 01:02:23 | Re: Link requirements creep |