On 21/07/11 23:03, mdxxd wrote: > I'm still not sure what should I get. If i understand correctly Greg > message, despite my workload, i7 won't have much benefit for me and I should > get i5(i7=4 cores with HT=8, i5=4 cores)? Probably, yeah. To be sure, you should *measure* your current workload. Get an idea of how many concurrent queries you have running and whether they're limited by CPU time or disk access. You're trying to ask for an answer without providing all of the question. The whole question is "Given my current workload, which looks like <this>, THEN what kind of computer should I get?" Great hardware for one workload can be crappy hardware for another workload. Greg knows about Poker Tracker, so he's probably going to be much more able to guestimate what you need without sufficient information. Follow his advice when in doubt. > From Scot/Craig I understood that I'm going to want to have my whole DB fit > into my RAM. But I don't think it is possible, even with 16GB RAM. From Greg > I understood that I only need the data that is being processed to fit into > my RAM. So i'm a bit confused. Should I get 8GB or 16GB? To answer this accurately, you need to know more about your database. How big is it right now? In bytes on disk? use pg_database_size() : http://www.postgresql.org/docs/current/interactive/functions-admin.html Are all the tables used frequently? Or are some of them "history" tables that are less used? You can use some of the statistics PostgreSQL collects to find out more about your use. http://www.postgresql.org/docs/current/static/monitoring-stats.html What you need for best performance is to make sure that all the _heavily_ _used_ parts of the database fit in RAM. This might be all the database, or it might only be a small fragment of it. If you cannot achieve that, then you need to make sure that your indexes fit in RAM and that you have fast disks. Whether you need fast sequential access, fast random access, or both depends a lot on your query patterns. > SSD: > This one is the most tricky. I read that consumer SSD is not reliable > enough(can have BSOD, can cause in data corruption, in case of power > shutdown data might be lost etc), also I read that SQL will tear-up a > consumer SSD. Greg notes that the Intel 320s are a safe(ish) consumer SSD, but they're buggy at the moment - see Greg's post today - so they should be used in RAID 1 or with extremely frequent backups. As for SQL "tearing up" an SSD: It has nothing to do with SQL. The point is that SSDs have a LIMITED WRITE LIFE. You can only write and overwrite so much data before they'll die. Exactly when is unpredictable, but it'll happen sooner the more you write to them. A read-only SQL database won't affect an SSD at all. A read-mostly database probably won't generate anywhere near as much write activity as your regular Windows updates, program updates, work with documents, temporary file access, etc. It's only when working with databases that are quite write-heavy (especially REwrite activity) that can cause issues. Even then it's hard to kill most SSDs within a couple of years unless you're unlucky. The answer here is: Get ones that're power-loss safe like the Intel 320s, run them in RAID 1, and keep backups. > Therefore i'm not sure what should I do. Getting 2 7200 rpm > hdd's in raid 0 will still cause big bottleneck right? You haven't provided enough data to answer that. If your DB can fit in RAM, or at least the heavily used parts can, then a single 5400RPM disk might be good enough for a low write load! If it doesn't fit in RAM, there's no such thing as storage that is too fast. > Getting an SSD and > UPS for power shutdown protection should cut it or is it still not reliable > enough and prone to failure(or slowing down due to massive write)? What > should I do? Keep good backups. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
