Re: Partitioning Vs. Split Databases - performance?

From: Benjamin Smith <lists(at)benjamindsmith(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Partitioning Vs. Split Databases - performance?
Date: 2006-12-21 23:22:11
Message-ID: 200612211522.11957.lists@benjamindsmith.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2006-12-21 23:25:55 Re: Partitioning Vs. Split Databases - performance?
Previous Message Joshua D. Drake 2006-12-21 23:15:55 Re: Partitioning Vs. Split Databases - performance?