Re: Maximum database size

> Richard, nice link.
>
> i guess only "slow" databases can win all these awards
> ;-)
>
> http://www.postgresql.org/about/awards
>
> seriously, though, i saw "asynchronous replication" as
> one of pgsql's features. what does this mean in
> practical terms? is it easy to set up, or is it quite
> complex?

I haven't quite gotten to replication myself. However, on the admin list it is a feature that
comes up pretty often. Also, Point In Time Recovery (PITR) seems to be a popular subject lately
also.

this page describe a synchronous solution.
http://archives.postgresql.org/pgsql-admin/2005-10/msg00240.php

This thread discusses a little bit about how Slony work.
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01266.php

From what I've read, Slony can be used to do the following things:

1. provide a secondary server in as a hot standby in case of primary server failure
2. Provide 1 Primary server for inserts/updates/delete and one or more secondary servers for
reporting from selects. I would imagine that the writing server would be optimized for heavy
writing while the reporting servers would be optimized for quick queries. However, IIRC only the
primary server can be written to.

> also, the size of postgresql is unlimited, however,
> there *must* be a point at which performance begins to
> significantly suffer. do we know what that point is
> on a server with modern specs? are their ways to
> minimize this? for example, create a cluster of pgsql
> servers to handle the load?

I'll defer this question for someone with more experience. :-)

>
> these questions don't impact me today, but they may
> some day.
>
> thanks,
>
> oe1
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>