/ Check-in [b13dae1c]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix a typo in the in-tree begin-concurrent documentation
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | begin-concurrent
Files: files | file ages | folders
SHA3-256: b13dae1cb3f9e20b6dcd697b1d11316e88b6c2d7c8dfe1aebc80ad88827dc887
User & Date: drh 2020-02-10 19:37:20
Wiki:begin-concurrent
Context
2020-02-10
19:37
Fix a typo in the in-tree begin-concurrent documentation (Leaf check-in: b13dae1c user: drh tags: begin-concurrent)
2020-02-04
20:08
Merge latest trunk changes, including the SQLITE_ENABLE_CORRUPT_PGNO patch, into this branch. (check-in: f253618a user: dan tags: begin-concurrent)
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to doc/begin_concurrent.md.

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
...
100
101
102
103
104
105
106
107
    rows with vastly different values for "a" will not (as the keys will likly
    be stored on different pages).

Note that, in SQLite, if values are not explicitly supplied for an INTEGER
PRIMARY KEY, as for example in:

>
     INSERT INTO t1(b) VALUES(<blob-value>);

then monotonically increasing values are assigned automatically. This is
terrible for concurrency, as it all but ensures that all new rows are 
added to the same database page. In such situations, it is better to
explicitly assign random values to INTEGER PRIMARY KEY fields.

This problem also comes up for non-WITHOUT ROWID tables that do not have an
................................................................................
rows.

The nature of some types of indexes, for example indexes on timestamp fields,
can also cause problems (as concurrent transactions may assign similar
timestamps that will be stored on the same db page to new records). In these
cases the database schema may need to be rethought to increase the concurrency
provided by page-level-locking.








|







 







<
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
...
100
101
102
103
104
105
106

    rows with vastly different values for "a" will not (as the keys will likly
    be stored on different pages).

Note that, in SQLite, if values are not explicitly supplied for an INTEGER
PRIMARY KEY, as for example in:

>
     INSERT INTO t1(b) VALUES(<blob-value>);

then monotonically increasing values are assigned automatically. This is
terrible for concurrency, as it all but ensures that all new rows are 
added to the same database page. In such situations, it is better to
explicitly assign random values to INTEGER PRIMARY KEY fields.

This problem also comes up for non-WITHOUT ROWID tables that do not have an
................................................................................
rows.

The nature of some types of indexes, for example indexes on timestamp fields,
can also cause problems (as concurrent transactions may assign similar
timestamps that will be stored on the same db page to new records). In these
cases the database schema may need to be rethought to increase the concurrency
provided by page-level-locking.