On Tue, Sep 10, 2019 at 2:09 PM Marek Wieckowski <wiec...@gmail.com> wrote:
> Yes, indeed works. Great, thank you! > Note though that it has performance implications perhaps. This changes to physical structure of the table, to be stored as an index basically. So if you do lots of insertions "in the middle", you could have "write amplifications". WITHOUT ROWID tables are ideal for read-mostly tables, and function as-if the table is an index that covers all columns. So there's no need for separate IO for the index (to lookup a PK) then to its table (to lookup the actual row), it's just one IO. It's no different from updating an index, except indexes are typically "skinnier" (have fewer and smaller columns) than their corresponding tables, limiting the impact. So "fat" tables, with large rows, and lost of inserts/updates, is basically the worse case scenario for such WITHOUT ROWID tables. It works, no issue there, and as typical of SQLite is often fast enough for most DB sizes, but it *can* matter. Just be aware of it. My $0.02. --DD https://www.sqlite.org/withoutrowid.html _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
