On Wed, Mar 22, 2006 at 07:35:32PM +0100, Daniel Franke wrote: > > I can tell you that even 750M rows wouldn't be a huge deal for PostgreSQL, > > and 20G of data is nothing. Though your table would take somewhere > > around 30G due to the higher per-row overhead in PostgreSQL; I'm not > > really sure how large the indexes would be. > > AFAIK, PostgreSQL is implemented in a client-server architecture. > For maintainability, I try to avoid such a thing. It is, but I wouldn't let that scare you off. 8.1 with a few config tweaks (mostly just to enable automatic vacuums) is very, very hands-off. Of course if SQLite suffices it'll probably be even more hands off. :) > The data could easily be grouped by chromosome, but I would like to avoid > this, too. I expect, it'd be sort of an hassle to do multi-chromosome > queries.
Possibly. I honestly have no idea how partitioning works in SQLite, only in PostgreSQL. Everything would appear as a single table in PostgreSQL, and if you added some rules you'd even be able to insert/update/delete from that single table. But partitioning is not fast=true, so you'd need to do some testing to see how much it helped you. (And indeed, how much different schemes helped you). -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
