SQLite

Check-in [b13dae1cb3]
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
Timelines: family | ancestors | descendants | both | begin-concurrent
Files: files | file ages | folders
SHA3-256: b13dae1cb3f9e20b6dcd697b1d11316e88b6c2d7c8dfe1aebc80ad88827dc887
User & Date: drh 2020-02-10 19:37:20.516
Context
2020-04-09
18:29
Merge recent trunk enhancements into the begin-concurrent branch. (check-in: 92f71a88c4 user: drh tags: begin-concurrent)
2020-02-10
19:37
Fix a typo in the in-tree begin-concurrent documentation (check-in: b13dae1cb3 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: f253618ac6 user: dan tags: begin-concurrent)
Changes
Unified Diff Ignore Whitespace Patch
Changes to doc/begin_concurrent.md.
︙︙
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

    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








|








72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

    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
︙︙
100
101
102
103
104
105
106
107

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.









<

100
101
102
103
104
105
106


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.