Schemas vs partitioning vs multiple databases for archiving

From: Bartel Viljoen <bartel(at)ncc(dot)co(dot)za>
To: "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org>
Subject: Schemas vs partitioning vs multiple databases for archiving
Date: 2012-08-18 08:05:02
Message-ID: 48E9F17CEB87D44695668E679BE3229F4A3CA0A1EA@IRIS.dm-ncc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dear mailing list.

My current application make use of partitioning by creating a new child table which holds transaction records for every month. I've notice that after a couple of months depending on the hardware at some of our clients the inserts become very slow. The reason memory. I don't want to delete old child tables even though they may be queried seldom and we can't upgrade memory since most clients are far and remote.
I'm in the design faze of a new GUI and DB layout, what are my options.

Create a DB for each month.
Create a Schema for each month. Example

Schema layout
Public.schema (will have all tables and the current months transaction table)
Jan2012.schema (This will just have the archive transaction table for Jan 2012)
Feb2012.schema
Mrt2012.schema

I've red a couple of articles regarding data warehousing but they don't mention schema's to split large transaction tables.

Will multiple schema's solve my problem ?

Regards

Bartel Viljoen

[cid:ncc-line7282.png]
[cid:ncc-sig251f.png]<http://www.ncc.co.za> Network & Computing Consultants (Pty) Ltd
E-mail : bartel(at)ncc(dot)co(dot)za
Phone : 086 155 5444
Fax : 051 448 1214
Url : www.ncc.co.za<http://www.ncc.co.za>
[cid:ncc-line1d18.png]
E-mail Disclaimer<http://www.ncc.co.za/legal/email-disclaimer.html>

Disclaimer added by CodeTwo Exchange Rules 2007
www.codetwo.com<http://www.codetwo.com>

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2012-08-18 08:13:40 Re: Schemas vs partitioning vs multiple databases for archiving
Previous Message Jasen Betts 2012-08-18 07:12:20 Re: Alternatives to very large tables with many performance-killing indicies?