On 5 Feb 2019, at 10:12pm, Gerlando Falauto <gerlando.fala...@gmail.com> wrote:
> I actually started off with source1,source2,ts as the primary key and for > some reason (which I no longer remember) I thought it would be wise to use a > ROWID and add an index instead. That is probably the right solution. There are reasons to keep the primary key very short, and ROWID is about as short as a SQLite value can be. > [...] > > I pre-populated the table with a realistic use case scenario and ran ANALYZE. > I'm not planning on using ANALYZE on the real system -- though I might indeed > pre-populate sqlite_stat1 with typical values as suggested in the docs. Having run ANALYZE on your 'typical' data, you can copy the resulting sqlite_stat1 table onto production systems, even though the tables it refers to are empty. ANALYZE not only analyzes the contents of your tables but also your indexes. If you add or drop indexes, it's useful to run ANALYZE again. ANALYZE is the number 1 fastest easiest tool to provide SQLite with the information it needs to pick the best query plan. As a human you can't possibly hope to match it. If your system has a yearly maintenance procedure, it's good to include ANALYZE. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
