From: | Tzahi Fadida <tzahi_ml(at)myrealbox(dot)com> |
---|---|
To: | 'Mike Nolan' <nolan(at)gw(dot)tssi(dot)com>, 'Christopher Browne' <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a peer-to-peer server solution with PG? |
Date: | 2005-02-05 03:17:34 |
Message-ID: | 009801c50b31$428f7c90$0b00a8c0@llord |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I am just a newbie but logically:
Maybe the answer to that is much simpler.
Ask your network officer to tell you whats the bandwidth you
have on your current office and remote office.
whats the avg:
a. website bandwidth.
b. current postgress office bandwidth.
I never used replication but it seems to me you'll need
a+2*b bandwidth at your current office and 2*b at your remote office
for the period of transition.
If your db size is C then you'll need (C/b)/3600 hrs in transition time.
do the math and if it fits great. If not, well...
Regards,
tzahi.
> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Mike Nolan
> Sent: Friday, February 04, 2005 12:57 PM
> To: Christopher Browne
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Is there a peer-to-peer server
> solution with PG?
>
>
> > If you have so much update load that one server cannot
> accomodate that
> > load, then you should wonder why you'd expect that causing
> every one
> > of these updates to be applied to (say) 3 servers would "diminish"
> > this burden.
>
> The update/query load isn't the real issue here, it's that
> these two servers will be 800 miles apart and there are some
> advantages in having each office connect to its local
> database rather than having one of them connect to the remote
> master.
>
> The Slony-1 approach will work, assuming I've got suffient
> network bandwidth to support it plus the traffic from the
> remote office plus
> exixting outside traffic from our public website.
>
> That's one of those things you just don't know will work
> until you have it built, so I'm looking for other options now
> while I have time to consider them. Once I get on-site in
> two weeks it'll a lot more hectic.
> --
> Mike Nolan
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index
> scan if your
> joining column's datatypes do not match
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | CN | 2005-02-05 03:59:11 | Can pg_restore also disable table CHECK contraint? |
Previous Message | Juan Casero (FL FLC) | 2005-02-05 03:03:34 | Re: plpgsql function errors |