138 ms·

I don't know what you're talking about. Sorting doesn't write to a database. You can check yourself by looking at last-modified-by timestamps on database files

I don't know what you're talking about. Sorting doesn't write to a database. You can check yourself by looking at last-modified-by timestamps on database files. They don't change. Gigantic sorts may need to write to a temp file but the temp file isn't part of the database, it's a temp file. And I don't know how Oracle works under the hood, but the entire point of transactional multiuser databases is that one user can read while another writes a transaction. A read neither commits nor rolls back a separate transaction currently in progress. It reads from the pre-transaction state.

chasil 1y ago
In Oracle, a user has a default tablespace, and a temporary tablespace. When a sort exceeds SORT AREA SIZE, then it writes into a sort segment in their registered temporary tablespace. Any or all of the datafiles behind this tablespace will show updated mtime. All users share a single sort segment within a tablespace. And users running SELECT will write to the database if a delayed block cleanout needs to occur. https://asktom.oracle.com/ords/asktom.search?tag=delayed-block-cleanout https://asktom.oracle.com/ords/asktom.search?tag=delayed-blo...
- crazygringo 1y ago
  All of that sounds like implementation details to do with files. No logical database writing occurs. The relational data in the database cannot be changed by a SELECT command, which is the point of user permissions. Even if temp disk space is used or stale data gets cleaned up in the process, that is irrelevant in the context of preventing inserts/updates/deletes. So not sure why you're bringing it up?
  - chasil 1y ago
    Logical? If the transaction committed, then the block metadata must change, but the row content remains the same. If the transaction is not active and did not commit, then the uncommitted data must be discarded, and the saved rollback must be restored. That does not fit within what I assume to be your distinction between a physical and a logical write. It does preserve acid.

chasil 1y ago

In Oracle, a user has a default tablespace, and a temporary tablespace. When a sort exceeds SORT AREA SIZE, then it writes into a sort segment in their registered temporary tablespace. Any or all of the datafiles behind this tablespace will show updated mtime. All users share a single sort segment within a tablespace. And users running SELECT will write to the database if a delayed block cleanout needs to occur. https://asktom.oracle.com/ords/asktom.search?tag=delayed-block-cleanout https://asktom.oracle.com/ords/asktom.search?tag=delayed-blo...

crazygringo 1y ago
All of that sounds like implementation details to do with files. No logical database writing occurs. The relational data in the database cannot be changed by a SELECT command, which is the point of user permissions. Even if temp disk space is used or stale data gets cleaned up in the process, that is irrelevant in the context of preventing inserts/updates/deletes. So not sure why you're bringing it up?
- chasil 1y ago
  Logical? If the transaction committed, then the block metadata must change, but the row content remains the same. If the transaction is not active and did not commit, then the uncommitted data must be discarded, and the saved rollback must be restored. That does not fit within what I assume to be your distinction between a physical and a logical write. It does preserve acid.