I'm just top posting this because this whole thread needs a reset before it goes any farther.
Start with a real description of these hosts - Number and types of disks, filesystem configs, processors, memory, OS, etc. If your db is small enough to fit into RAM, please show us the db config you are using which ensures that you are making best use of available RAM, etc.
Then we need to know what your test looks like - showing us a query and an explain plan without any info about the table structure, indexes, number of rows, and table usage patterns doesn't provide anywhere near enough info to diagnose inefficiency.
There are several documents linked right from the page for this mailing list that describe exactly how to go about providing enough info to get help from the list. Please read through them, then update us with the necessary information, and I'm sure we'll be able to offer you some insight into what is going on.
And for the record, your app probably doesn't need to change to use table partitioning, at least when selecting data. Depending upon how data is loaded, you may need to change how you do inserts. But it is impossible to comment on whether partitioning might help you without knowing table structure, value distributions, query patterns, and number of rows in the table. If you are always selecting over the whole range of data, partitioning isn't likely to buy you anything, for example.
