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>
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? |