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

Re: Need help to organize database

From: "Frank D(dot) Engel, Jr(dot)" <fde101(at)fjrhome(dot)net>
To: General PostgreSQL list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Need help to organize database
Date: 2004-12-21 22:50:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Hash: SHA1

Why would it be?

The only real advantage to what you are suggesting would be slightly 
reduced disk space usage, and just maybe *very* slightly improved 
performance on low-memory servers, or servers with very slow disks, but 
I find it unlikely that this would really be significant enough to be 

There are greater advantages to not doing something like that: easier 
coding of your front-end software, a layout which is a bit more 
comprehensible, making future maintenance of the design and code much 
easier, etc.

Also, given the amount of data you are talking about, and assuming that 
you are inserting all of this data in one big lump, you may wish to 
VACUUM FULL after doing your INSERTs (not after each one,  of course -- 
after doing all of the INSERTs, or after doing a big chunk of them.  If 
data is inserted incrementally over a period of time, then just do the 
VACUUM ANALYZE every so often during that time, and you shouldn't have 
a problem).

On Dec 21, 2004, at 8:24 PM, Vladimir S. Petukhov wrote:
> Yes, of course, this is example only.
> But relation between tables is not important now...
> I whant to ask - is it a good idea to store 1 time's data (value1-4) 
> per row
> in 24*31 rows? May be it is better and quicker to store, for example, 2
> time's data per row (value1-4, day 1,  value1-4, day 2) or other 
> structure?
- -----------------------------------------------------------
Frank D. Engel, Jr.  <fde101(at)fjrhome(dot)net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
Version: GnuPG v1.2.4 (Darwin)


$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at

In response to


pgsql-general by date

Next:From: Paul TillotsonDate: 2004-12-22 00:09:39
Subject: tool for incrementally shrinking bloated tables
Previous:From: Frank D. Engel, Jr.Date: 2004-12-21 22:41:59
Subject: Re: PostgreSQL training curriculum

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