db_file_multiblock_read_count causing full scans to take longer?

After having it set in our dev instances for a week, I raised our db_file_multiblock_read_count in production from 16 to 128 (based on documented 10046 traces). After getting tickets about certain operations being slow, I identified a select query against our NOTES table as doing a full scan, which it did previously as well. However the full scan now takes 133 seconds, as opposed to 8-10 seconds with db_file_multiblock_read_count of 16 or 32.

Granted, there needs to be some query tuning done (or a crutch index in the meantime) so that we aren't doing this full scan, but I thought that db_file_multiblock_read_count would make full scans take less time, if anything. Autotraces and query plans show similar numbers, as far as I can tell.

Any thoughts?

--
http://www.freelists.org/webpage/oracle-l