SELECTing from a large table vs small table

Question

I posted a question few months back about teh comparison between INSERTing to a large table vs small table ( fewer number of rows ), in terms of time taken.
The general consensus seemed to be that it would be teh same, except for teh time taken to update the index ( which will be negligible ).
1. But now, following teh same logic, I m confused why SELECTINg from a large table should be more time taking ("expensive" ) than SELECTing from a small table.
( SELECTing using an index )
My understanding of how Oracle works internally is this :
It will first locate the ROWID from teh B-Tree that stores the index.
( This operation is O(log N ) based on B-Tree )
ROWID essentially contains teh file pointer offset of teh location of the data in teh disk.
And Oracle simply reads teh data from teh location it deduced from ROWID.
But then the only variable I see is searching teh B-Tree, which should take O(log N ) time for comparison ( N - number of rows )
Am I correct above.
2. Also I read that tables are partitioned for performance reasons. I read about various partiotion mechanisms. But cannot figure out how it can result in performance improvement.
Can somebody please help

Answer 1

user597961 wrote:
I posted a question few months back about teh comparison between INSERTing to a large table vs small table ( fewer number of rows ), in terms of time taken.
The general consensus seemed to be that it would be teh same, except for teh time taken to update the index ( which will be negligible ).
1. But now, following teh same logic, I m confused why SELECTINg from a large table should be more time taking ("expensive" ) than SELECTing from a small table.
( SELECTing using an index )
My understanding of how Oracle works internally is this :
It will first locate the ROWID from teh B-Tree that stores the index.
( This operation is O(log N ) based on B-Tree )
ROWID essentially contains teh file pointer offset of teh location of the data in teh disk.
And Oracle simply reads teh data from teh location it deduced from ROWID.
But then the only variable I see is searching teh B-Tree, which should take O(log N ) time for comparison ( N - number of rows )
Am I correct above.
2. Also I read that tables are partitioned for performance reasons. I read about various partiotion mechanisms. But cannot figure out how it can result in performance improvement.
Can somebody please helpIt's not going to be that simple. Before your first step (locate ROWID from index), it will first evaluate various access plans - potentially thousands of them - and choose the one that it thinks will be best. This evaluation will be based on the number of rows it anticipates having to retrieve, whether or not all of the requested data can be retrived from the index alone (without even going to the data segment), etc. etc etc. For each consideration it makes, you start with "all else being equal". Then figure there will be dozens, if not hundreds or thousands of these "all else being equal". Then once the plan is selected and the rubber meets the road, we have to contend with the fact "all else is hardly ever equal".