On Wed, Feb 8, 2017 at 4:50 PM, Hick Gunter <h...@scigames.at> wrote:
> This is with a generic, user definable table and index structure capable > virtual table implementation; it is not a "one module per table" statically > typed heavily optimized implementation. > Ah, that makes complete sense then. I didn't want the OP to think virtual tables were slower than native tables in the general case, especially since he mentioned memory arrays in C code. And indeed the virtual-table advantage I mentioned is with a different statically-typed vtable impl/module per vtable, with statically defined indexes, where the table structure is hard-coded in the vtable impl itself, and corresponds to a native "row" data structure. In that config one leverages the "front-end" of SQLite (parser and VDBE engine) and very little of the "back-end" (pager and btree), except when SQLite decides to make temporary tables for query processing I guess. FWIW. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users