On 05/09/2017 07:03 PM, Armand Pirvu (home) wrote:
>
> On May 9, 2017, at 7:11 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
>> On 05/09/2017 05:02 PM, armand pirvu wrote:
>>> Well
>>> Jt1 is prod and jt2 is dev
>>
>> You are talking schemas, not databases, correct?
>>
>>
>
> Correct
>
>>> Before someone pushes to prod it does work in dev. The jdbc connection
>>
>> That would concern me, as anything bad that happened in the dev schema could bring the entire database to its knees,
includingthe prod schema.
>>
>> How does data get into the prod schema if the connection is to the dev schema?
>
> If you are a user in say category B you get to dev where you do your thing. If you deem okay you push to prod.
> If you are a user in say category A you get to prod
>
>
>
>>
>>> routes to jt2. In the mean time it wad needed that some tables in prod are synced at all times from dev. Hence the
view/fdw.
>>> What I meant by connections was more to say the type of load or users doing something in each schema.
>>
>> The issue being that if you are pushing data from jt2 --> jt1 you are also pushing the load in the same direction.
>
> I see but short of using something like Slony in between the two schemas I don’t see a pretty simple choice
Create a separate dev database or cluster?
>
>
>>
>>> So my questions still remain
>
> And about the plan from the fdw am I right or wrong ? I am inclined to say I am right based on the numbers in the
timings
The timings where for a simple select. I am going to say doing something
that INSERTs/UPDATEs is going to be different. Still since a FDW
involves establishing another connection and passing data across it I
would say it is going to be less efficient.
>
>
>>> Sent from my iPhone
>>> On May 9, 2017, at 6:52 PM, Adrian Klaver <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
>>
>> --
>> Adrian Klaver
>> adrian.klaver@aklaver.com
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
