Which database (DBMS) can best handle large tables?

Question

I also have a very large table in SQL Server (2008 R2 Developer Edition) that is having some performance problems.

I was wondering if another DBMS would be better for handling large tables. I'm mainly only considering the following systems: SQL Server 2008, MySQL, and PostgreSQL 9.0.

Or, as the referenced question above eludes to, is the table size and performance mainly a factor of indexes and caching?

Also, would greater normalization improve performance, or hinder it?

Edit:

One of the comments below claims I was vague. I have over 20 million rows (20 years of stock data & 2 years of options data), and I am trying to figure out how to improve performance by an order of magnitude. I only care about read/calculation performance; I don't care about write performance. The only writes are during data refreshes, and those are BulkCopy.

I have some indexes already, but hopefully I'm doing something wrong because I need to speed things up a lot. I need to start looking at my queries too.

The comments and answers provided already helped me understand how to start profiling my database. I'm a programmer, not a DBA (therefore Marco's book recommendation is perfect). I don't have that much database experience and I've never profiled a database before. I will try these suggestions and report back if necessary. Thank you!

Answer 1

80M rows is not big. You just need to learn how to design and query data of that size. Which might include normalization, denormalization, clustering, indexing but very often the tradeoffs are deeper that they seem. Adding indexes can actually hurt performance even for reading, for instance, if the optimizer is not good enough or decides upon the wrong statistics.

I suggest you read Refactoring SQL Applications because it approaches the problem not from a "DB tuner" but from a developer's point of view.

The book is by the author of The Art of SQL and compares Oracle, SQL Server and MySQL under many scenarios. It's pragmatic and comes with some useful graphs.

I would stay away from MySQL unless forced to. Postgres 9.0 rocks according to several definitions of "rock" but I would still use 8.4 in production for a few months.

And if you want people to help you with this table, provide as many details as possible: schema, indexes, data distribution, pattern of usage, etc.