mirror of
https://github.com/jart/cosmopolitan.git
synced 2025-07-03 17:58:30 +00:00
Get SQLite to build
* changed headers * removed redundant declarations * ran clang-format * added sqlite3.mk
This commit is contained in:
parent
644f290035
commit
919b6fec10
156 changed files with 2847 additions and 6772 deletions
31
third_party/sqlite3/vdbesort.c
vendored
31
third_party/sqlite3/vdbesort.c
vendored
|
@ -55,7 +55,7 @@
|
|||
** is like Close() followed by Init() only
|
||||
** much faster.
|
||||
**
|
||||
** The interfaces above must be called in a particular order. Write() can
|
||||
** The interfaces above must be called in a particular order. Write() can
|
||||
** only occur in between Init()/Reset() and Rewind(). Next(), Rowkey(), and
|
||||
** Compare() can only occur in between Rewind() and Close()/Reset(). i.e.
|
||||
**
|
||||
|
@ -63,16 +63,16 @@
|
|||
** for each record: Write()
|
||||
** Rewind()
|
||||
** Rowkey()/Compare()
|
||||
** Next()
|
||||
** Next()
|
||||
** Close()
|
||||
**
|
||||
** Algorithm:
|
||||
**
|
||||
** Records passed to the sorter via calls to Write() are initially held
|
||||
** Records passed to the sorter via calls to Write() are initially held
|
||||
** unsorted in main memory. Assuming the amount of memory used never exceeds
|
||||
** a threshold, when Rewind() is called the set of records is sorted using
|
||||
** an in-memory merge sort. In this case, no temporary files are required
|
||||
** and subsequent calls to Rowkey(), Next() and Compare() read records
|
||||
** and subsequent calls to Rowkey(), Next() and Compare() read records
|
||||
** directly from main memory.
|
||||
**
|
||||
** If the amount of space used to store records in main memory exceeds the
|
||||
|
@ -82,10 +82,10 @@
|
|||
** of PMAs may be created by merging existing PMAs together - for example
|
||||
** merging two or more level-0 PMAs together creates a level-1 PMA.
|
||||
**
|
||||
** The threshold for the amount of main memory to use before flushing
|
||||
** The threshold for the amount of main memory to use before flushing
|
||||
** records to a PMA is roughly the same as the limit configured for the
|
||||
** page-cache of the main database. Specifically, the threshold is set to
|
||||
** the value returned by "PRAGMA main.page_size" multipled by
|
||||
** page-cache of the main database. Specifically, the threshold is set to
|
||||
** the value returned by "PRAGMA main.page_size" multipled by
|
||||
** that returned by "PRAGMA main.cache_size", in bytes.
|
||||
**
|
||||
** If the sorter is running in single-threaded mode, then all PMAs generated
|
||||
|
@ -102,7 +102,7 @@
|
|||
** than zero, and (b) worker threads have been enabled at runtime by calling
|
||||
** "PRAGMA threads=N" with some value of N greater than 0.
|
||||
**
|
||||
** When Rewind() is called, any data remaining in memory is flushed to a
|
||||
** When Rewind() is called, any data remaining in memory is flushed to a
|
||||
** final PMA. So at this point the data is stored in some number of sorted
|
||||
** PMAs within temporary files on disk.
|
||||
**
|
||||
|
@ -114,16 +114,16 @@
|
|||
**
|
||||
** Or, if running in multi-threaded mode, then a background thread is
|
||||
** launched to merge the existing PMAs. Once the background thread has
|
||||
** merged T bytes of data into a single sorted PMA, the main thread
|
||||
** merged T bytes of data into a single sorted PMA, the main thread
|
||||
** begins reading keys from that PMA while the background thread proceeds
|
||||
** with merging the next T bytes of data. And so on.
|
||||
**
|
||||
** Parameter T is set to half the value of the memory threshold used
|
||||
** Parameter T is set to half the value of the memory threshold used
|
||||
** by Write() above to determine when to create a new PMA.
|
||||
**
|
||||
** If there are more than SORTER_MAX_MERGE_COUNT PMAs in total when
|
||||
** Rewind() is called, then a hierarchy of incremental-merges is used.
|
||||
** First, T bytes of data from the first SORTER_MAX_MERGE_COUNT PMAs on
|
||||
** If there are more than SORTER_MAX_MERGE_COUNT PMAs in total when
|
||||
** Rewind() is called, then a hierarchy of incremental-merges is used.
|
||||
** First, T bytes of data from the first SORTER_MAX_MERGE_COUNT PMAs on
|
||||
** disk are merged together. Then T bytes of data from the second set, and
|
||||
** so on, such that no operation ever merges more than SORTER_MAX_MERGE_COUNT
|
||||
** PMAs at a time. This done is to improve locality.
|
||||
|
@ -135,8 +135,9 @@
|
|||
** thread to merge the output of each of the others to a single PMA for
|
||||
** the main thread to read from.
|
||||
*/
|
||||
#include "sqliteInt.h"
|
||||
#include "vdbeInt.h"
|
||||
#include "third_party/sqlite3/sqliteInt.h"
|
||||
#include "third_party/sqlite3/vdbeInt.h"
|
||||
/* clang-format off */
|
||||
|
||||
/*
|
||||
** If SQLITE_DEBUG_SORTER_THREADS is defined, this module outputs various
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue