> I've got an application that needs to chunk through ~2GB of data. The 
> data is ~7000 different sets of 300 records each. I put all of the data 
> into a postgres database but that doesn't look like its going to work 
> because of how the data lives on the disk.

Your problem is curable through 4 steps:

1) adjust your postgresql.conf to appropriate levels for memory usage.

2) if those sets of 300 are blocks in some contiguous order, then cluster them 
to force their physical ordering on disk to be the same order you want to 
read them in.   This will require you to re-cluster whenever you change a 
significant number of records, but from the sound of it that happens in 

3) Get better disks, preferrably a RAID array, or just very fast scsi if the 
database is small.    If you're budget-constrained, Linux software raid (or 
BSD raid) on IDE disks is cheap.  What kind of RAID depends on what else 
you'll be doing with the app; RAID 5 is better for read-only access, RAID 1+0 
is better for read-write.

4) Make sure that you aren't dumping the data to the same disk postgreSQL 
lives on!   Preferably, make sure that your swap partition is on a different 
disk/array from postgresql.   If the computing app is complex and requires 
disk reads aside from postgres data, you should make sure that it lives on 
yet another disk.   Or you can simplify this with a good, really large 
multi-channel RAID array.

-Josh Berkus
 Aglio Database Solutions
 San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to