On 10/05/10 23:20, Vick Khera wrote:
> On Sat, May 8, 2010 at 12:12 AM, Mike Christensen wrote:
>> What's the best way to do this? Looks like something like pgPool
>> might be what I want, but I haven't looked into it deeply yet.
>
> I don't think your requirement and postgres are consistent wit
On Mon, May 10, 2010 at 8:59 PM, John R Pierce wrote:
> Scott Marlowe wrote:
>>>
>>> Is there any sort of abstraction layer (like in the driver level) that
>>> can abstract that and just make updates go to one DB and reads
>>> round-robin to other DBs? Hopefully there's a way to make this design
Scott Marlowe wrote:
Is there any sort of abstraction layer (like in the driver level) that
can abstract that and just make updates go to one DB and reads
round-robin to other DBs? Hopefully there's a way to make this design
simple to implement.
Pretty sure pgpool can do the "read from th
Man that sounds awesome. I need that now. So does that mean you'd
have one beefy SQL server for all the updates and everything writes to
that, and then you'd have a bunch of read-only servers and new data
trickles into them from the master continuously?
Mike
On Mon, May 10, 2010 at 6:09 PM, Sco
On Mon, May 10, 2010 at 8:00 PM, Mike Christensen wrote:
> The concept of updating one database and doing all your reads from
> another database is kinda confusing to me. Does that mean you have to
> design your whole app around that concept, have a different connection
> string and what not for
The concept of updating one database and doing all your reads from
another database is kinda confusing to me. Does that mean you have to
design your whole app around that concept, have a different connection
string and what not for your "writable" database and "read-only
databases"? I'm using Cas
On Mon, May 10, 2010 at 7:21 PM, Mike Christensen wrote:
> Man that sounds awesome. I need that now. So does that mean you'd
> have one beefy SQL server for all the updates and everything writes to
> that, and then you'd have a bunch of read-only servers and new data
> trickles into them from th
On Mon, May 10, 2010 at 7:04 PM, Mike Christensen wrote:
> Thanks for the advice. In that case, I'll stick with the standard
> approach of having a single SQL server and several web frontends and
> employ a caching mechanism such as memcache as well. Thanks!
And with 9.0 it will be pretty easy
Thanks for the advice. In that case, I'll stick with the standard
approach of having a single SQL server and several web frontends and
employ a caching mechanism such as memcache as well. Thanks!
Mike
On Mon, May 10, 2010 at 9:30 AM, Scott Marlowe wrote:
> On Fri, May 7, 2010 at 10:12 PM, Mike
On Fri, May 7, 2010 at 10:12 PM, Mike Christensen wrote:
> I'm considering using a cloud hosting solution for my website. It
> will probably be either Amazon, Rackspace or Hosting.com. I'm still
> comparing. Either way, my site will consist of multiple virtual
> server instances that I can crea
On Sat, May 8, 2010 at 12:12 AM, Mike Christensen wrote:
> What's the best way to do this? Looks like something like pgPool
> might be what I want, but I haven't looked into it deeply yet.
I don't think your requirement and postgres are consistent with each
other.Unless your data volume is *
I'm considering using a cloud hosting solution for my website. It
will probably be either Amazon, Rackspace or Hosting.com. I'm still
comparing. Either way, my site will consist of multiple virtual
server instances that I can create and destroy as needed. Each
virtual machine instance will be s
12 matches
Mail list logo
