i have ms-sql server experience with reporting queries on a (realtime replica) database receiving hundreds of rows / second.
The short answer is always going to be "it depends"; the answer can be anything between 1000 and 1150 (or even 990 to 1160 if you run with "Read Uncommitted" as mentioned by Robbie Dee)
in sql server a table scan,by default, locks pages as it reads, ensuring that re-use of the same row doesn't give a silly-inconsistent answer. Writes which happen after you start the query, but involving a row/data page you have not yet read will be visable to you.
Adjusting the isolation level can change this in 2 ways:
1) with 'snapshot' isolation, you will not see writes which are requested after you start the query. (what happens to the write depends on if you have a row versioning database, such as oracle, or sql-server with snapshot isolation enabled)
2) when you use a more permissive "allow dirty reads" Read Uncommited (or a table 'with (nolock)' ) then what happens is undefined. in particuar 3 extra scenarios can occur when reading a full page that is about to be split:
a) you are at the end of a page, and the new page is ahead of the table scan; you will read all the rows copied to the new page twice. (potential primary key violation in the returned results, or if this is an update, the same row returned twice with different data.)
b) you are at the beginning of the page, and the new page is behind of the current table scan; the rows which are moved from the current page to the new one will not be read, resulting in matching rows not being returned.
c) your read query isn't a table scan, but utilizes an index, which holds row id's: the change in rowID caused by the page split may result in the row changing and results which don't' match your query being returned.
note: in sql server almost any modification (including deleting rows) can cause a page split.