Skip site navigation (1) Skip section navigation (2)

Re: DB Design

From: Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>
To: "Michael Ryan S(dot) Puncia" <mpuncia(at)census(dot)gov(dot)ph>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: DB Design
Date: 2004-05-19 11:21:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, 2004-05-19 at 15:37 +0800, Michael Ryan S. Puncia wrote:
> Hi Guys,
>       My question is .. which is better design
>      1. Single Table with 50 million records or
>      2. Multiple Table using inheritance to the parents table

It's not that simple.

Given your e-mail address I assume you want to store Philippines Census
data in such a table, but does Census data fit well in a single flat
table structure?  Not from what I have seen here in NZ, but perhaps
Census is simpler there.

So to know what the best answer to that question is, people here will
surely need more and better information from you about database schema,
record size, indexing and query characteristics, and so on.

> I will use this only for query purpose ..

Then you may quite possibly want to consider a different database.
Particularly if it is single-user query purposes.

For example, there are some SQL databases that would load the entire
database into RAM from static files, and then allow query against this.
This can obviously give huge performance improvements in situations
where volatility is not a problem.


Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053,  Manners St,  Wellington
WEB:             PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201       MOB: +64(21)635-694      OFFICE: +64(4)499-2267
                       Do not overtax your powers.

In response to

  • DB Design at 2004-05-19 07:37:06 from Michael Ryan S. Puncia

pgsql-performance by date

Next:From: Joseph ShraibmanDate: 2004-05-19 19:26:31
Subject: shared buffer size on linux
Previous:From: Michael Ryan S. PunciaDate: 2004-05-19 07:37:06
Subject: DB Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group