precari0 wrote:

>
> SQL> insert into test(i) values (1);
> SQL> insert into test(i) values (2);
> SQL> insert into test(i) values (3);
> SQL> insert into test(i) values (4);
> SQL> insert into test(i) values (5);
> SQL> insert into test(i) values (6);
> SQL> insert into test(i) values (7);
> SQL> insert into test(i) values (8);
> SQL> insert into test(i) values (9);
> SQL> insert into test(i) values (0);

So we have 10 records in the table.

> 58 732
>
> -- A total of 10 pages were read from disk and another 98 from memory.

It means there were 98 requests for page read access. 10 of those
requests required a disk read to fill the page cache. The mentioned 98
requests don't necessarily mean different pages, some of them could be
different requests for the same page.

Usually, every record read from a table requires two page fetches
(pointer page and data page). So the above select should report about 20
fetches. Other ones could be related to both start/commit transaction
operations and the internal metadata selects performed by the engine.

> 58 761
>
> -- Only 29 pages were read from memory.

This roughly means 20 fetches for data and 9 fetches for transaction
management. Looks okay.

> -- Why so many memory reads on the previous select?

Because the engine selected the necessary metadata. After the first run,
they're cached and no more extra selects are required.

> -- I tried the same test on a bigger database and the results are
> really strange:
>
> SQL> select count(*) from bigtable;
> COUNT
> 825778
>
> 13405 1679681
>
> -- The page_reads value seems to be OK with the size of the table,
> but 1.6 milion page fetches?

~800K * 2 = ~1.6M : yes, this is correct.


Dmitry