Well, if you are getting true full table scans, then how do you propose to run those queries if you split the table into multiple tables? If you are getting full partition scans (ie. partition pruning but no index-based access) then the total size of the table is not relevant, it's just the size of the partitions being accessed that matters.

Your difference in performance might be due to a number of issues. For example, the optimizer might be making a bad choice about the best access method because you haven't updated both global and partition statistics. Alternatively the optimizer might just be responding to the different data volumes correctly, and an increased data volume gives longer response times.

I don't think that the answer is to split the table - you have already effectively done that by partitioning. The key would just be to make sure that the optimizer is leveraging the partitioning by giving you the pruning that you expect.