Re: Partitioning Vs. Split Databases - performance? - Mailing list pgsql-general

From Benjamin Smith
Subject Re: Partitioning Vs. Split Databases - performance?
Date
Msg-id 200612211522.11957.lists@benjamindsmith.com
Whole thread Raw
In response to Re: Partitioning Vs. Split Databases - performance?  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Partitioning Vs. Split Databases - performance?  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-general
On Thursday 21 December 2006 14:41, Joshua D. Drake wrote:
>You should read up on schemas and how they work. Plus the
> addition of schemas and table spaces means you can infinite scaling
> within the confines of your hardware itself.

Ok, so I'd like you to correct me if I'm wrong:

1) Schemas operate within a database. A schema is analogized as a filesystem
directory in the docs, except that you can't recurse schemas.

2) A database runs on one machine, with the following addenda:
    A) slony lets you copy that database to another system,
    B) pgtool lets you duplicate the database if you're real careful around
updating with unique IDs and aggregate functions,
    C) you can essentially do cross-machine RAID so that if your primary DB gets
hosed, you can fire up the backup machine and continue working.
    D) pg-cluster, a synchronous clustering solution appears to be new/unstable,
doesn't appear to be current to 8.x, and takes a performance hit on writes.

3) Thus, any service that splits up a database (EG: a schema) is subject to
all the limitations outlined in #2.

Did I miss anything?

--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978

pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Partitioning Vs. Split Databases - performance?
Next
From: Ron Johnson
Date:
Subject: Re: Partitioning Vs. Split Databases - performance?