Hi yall, although I've worked with databases for more than 7 years now, I'm petty new to PostgreSQL. I have an application using SQLite3 as an embedded SQL solution because it's simple and it can handle the load that *most* of my clients have. Because of that '*most*' part, because of the client/server way and because of the license, I'm think about start using PostgreSQL. My app uses only three tables: one has low read and really high write rates, a second has high read and low write and the third one is equally high on both. I need a db that can handle something like 500 operations/sec continuously. It's something like 250 writes/sec and 250 reads/sec. My databases uses indexes. Each table would have to handle 5 million rows/day. So I'm thinking about creating different tables (clusters?) to different days to make queries return faster. Am I right or there is no problem in having a 150 million (one month) rows on a table? All my data is e-mail traffic: user's quarentine, inbond traffic, outbond traffic, sender, recipients, subjects, attachments, etc... What do you people say, is it possible with PostgreSQL? What kind of hardware would I need to handle that kind of traffic? On a first test, at a badly tunned AMD Athlon XP 1800+ (ergh!) I could do 1400 writes/sec locally after I disabled fsync. We have UPSs, in the last year we only had 1 power failure. Thank you all for your tips. Best regards, Daniel Colchete
