Re: [rfc,patch] PL/Proxy in core

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
>

In response to

Responses

Browse pgsql-hackers by date

  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