On Tue, Mar 4, 2014 at 9:41 PM, Elefterios Stamatogiannakis <est...@gmail.com> wrote: > [...] Nevertheless, having people do crazy/clever hacks like that to avoid the > inefficiencies of an API, gives a hint that something might be problematic. > > In a previous email of mine, i had said half seriously/half joking about the > cost in Watts of SQLite's worldwide usage. For something that is so widely > used, even some % of efficiency improvement really makes a difference. It is > not an "SQLite destroys/saves civilization" kind of difference, but IMHO it > would be measurable in G/M Watts.
The SQLite developers clearly care about performance, that much is clear. But they also care about the "lite"-ness aspects too (and so does part of its community, judging by this list). They try to find the right balance for them, with ease of implementation/testing/maintenance as the last variable of this equation. One thing that IMHO long term might improve the situation would be if SQLite's own "native" tables would use the same Virtual Table API, because then any bottleneck would apply to all "tables", not just the VT ones, and would be more likely to be removed. And as recently discussed, the VT API would be forced to acquire ways to communicate with Explain Query Plan (for example) to notice Full Scans or Covering Indexes not just for the "native" tables. VTs came after the "native" tables, so the current situation is normal, but if all table accesses, "native" or otherwise, could go thru the same API in the future (in SQLite3 or Sqlite4), it would further decouple the "front-end" from the "back-end", and ensure no performance differences between "native" and "virtual" tables. Of course, the above is a "naive" abstract reflection which ignores the realities of VDBE, so it may sound rubbish to actual SQLite developers. Apologies for that. --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
