Re: [rfc,patch] PL/Proxy in core - Mailing list pgsql-hackers

From Steve Singer
Subject Re: [rfc,patch] PL/Proxy in core
Date
Msg-id BAYC1-PASMTP1593BA292B90A6EC638793ACCA0@CEZ.ICE
Whole thread Raw
In response to Re: [rfc,patch] PL/Proxy in core  ("Marko Kreen" <markokr@gmail.com>)
Responses Re: [rfc,patch] PL/Proxy in core  ("Marko Kreen" <markokr@gmail.com>)
List pgsql-hackers
On Sat, 17 May 2008, Marko Kreen wrote:

> On 5/17/08, Steve Singer <ssinger_pg@sympatico.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Link requirements creep
Next
From: Robert Lor
Date:
Subject: New DTrace probes proposal