SQLite

Check-in [51af2ade8e]
Login

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

Overview
Comment:Updates to the shared_schema.md notes document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | reuse-schema
Files: files | file ages | folders
SHA3-256: 51af2ade8eddae16a7290ab9676bcb4a677f0be72959640d0b664966398d8319
User & Date: drh 2019-06-03 14:02:58.467
Context
2019-07-08
21:32
Merge recent trunk enhancements into the reuse-schema branch. (check-in: fae92fee54 user: drh tags: reuse-schema)
2019-06-03
14:02
Updates to the shared_schema.md notes document. (check-in: 51af2ade8e user: drh tags: reuse-schema)
13:46
In the CLI, add ".help" text for the .shared-schema command. (check-in: 3ba6f790e0 user: drh tags: reuse-schema)
Changes
Unified Diff Ignore Whitespace Patch
Changes to doc/shared_schema.md. 
1
2
3
4

5
6
7
8
9




10


11
12
13
14
15
16
17


Shared-Schema Mode Notes
========================


This branch contains a patch to allow SQLite connections to share schemas
between database connections within the same process in order to save memory.
Schemas may be shared between multiple databases attached to the same or
distinct connection handles.





To activate shared-schemas, a database connection must be opened using the


sqlite3_open_v2() API with the SQLITE_OPEN_SHARED_SCHEMA
flag specified.  The main database and any attached databases will then share
an in-memory Schema object with any other database opened within the process
for which: 

  * the contents of the sqlite_master table, including all object names,
    SQL statements and root pages are identical, and





>
|




>
>
>
>
|
>
>








1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


Shared-Schema Mode Notes
========================

The [reuse-schema](/timeline?r=reuse-schema) branch contains changes 
to allow SQLite connections to share schemas
between database connections within the same process in order to save memory.
Schemas may be shared between multiple databases attached to the same or
distinct connection handles.

Compile with -DSQLITE\_ENABLE\_SHARED\_SCHEMA in order to enable the
shared-schema enhancement.  Enabling the shared-schema enhancement causes
approximately a 0.1% increase in CPU cycles consumed and about a 3000-byte
increase in the size of the library, even if shared-schema is never used.

Assuming the compile-time requirements are satisfied, the shared-schema
feature is engaged by opening the database connection using the
sqlite3_open_v2() API with the SQLITE_OPEN_SHARED_SCHEMA
flag specified.  The main database and any attached databases will then share
an in-memory Schema object with any other database opened within the process
for which: 

  * the contents of the sqlite_master table, including all object names,
    SQL statements and root pages are identical, and
︙︙
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

whether or not two databases are similar enough to share in-memory schemas,
and to fix minor problems that prevent them from doing so. To test if
two or more database are compatible, one database is opened directly using 
the shell tool and the following command issued:

        .shared-schema check <database-1> [<database-2>]...

where &lt;database-1;&gt; etc. are replaced with the names of database files
on disk. For each database specified on the command line, a single line of
output is produced. If the database can share an in-memory schema with the
main database opened by the shell tool, the output is of the form:

        <database> is compatible

Otherwise, if the database cannot share a schema with the main db, the output








|








45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

whether or not two databases are similar enough to share in-memory schemas,
and to fix minor problems that prevent them from doing so. To test if
two or more database are compatible, one database is opened directly using 
the shell tool and the following command issued:

        .shared-schema check <database-1> [<database-2>]...

where &lt;database-1&gt; etc. are replaced with the names of database files
on disk. For each database specified on the command line, a single line of
output is produced. If the database can share an in-memory schema with the
main database opened by the shell tool, the output is of the form:

        <database> is compatible

Otherwise, if the database cannot share a schema with the main db, the output
︙︙
129
130
131
132
133
134
135
136
137
138

virtual-table handles in the Table.pVTable list of each table. This would not
work, as (a) there is no guarantee that a connection will be assigned the same
Schema object each time it requests one from a schema-pool and (b) a single
Schema (and therefore Table) object may correspond to tables in two or more
databases attached to a single connection. Instead, all virtual-table handles
associated with a single database are stored in a linked-list headed at
Db.pVTable.











<
<
<

136
137
138
139
140
141
142




virtual-table handles in the Table.pVTable list of each table. This would not
work, as (a) there is no guarantee that a connection will be assigned the same
Schema object each time it requests one from a schema-pool and (b) a single
Schema (and therefore Table) object may correspond to tables in two or more
databases attached to a single connection. Instead, all virtual-table handles
associated with a single database are stored in a linked-list headed at
Db.pVTable.