Is it time to break out an API for schema lookup? That would seem to be the least work for the developers and would give people the chance to implement whatever strategy they need to manage large schemas, including storing them in the database in a structured manager, or a compressed in-memory representation.
> On Mar 16, 2017, at 11:57 PM, Richard Hipp <d...@sqlite.org> wrote: > > On 3/16/17, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: >> >> I just checked and the total character count for the trigger and index >> names themselves is only 23k, which is not even a tiny dent in 1.58MB. >> Is there a muliplying factor somewhere which would make this worth >> doing? > > I did say it was a "small step" :-) Great journeys begin with a single step. > >> >> Storing original SQL text such as SQL keywords surely consumes a lot >> of space (I am assuming this is what is done). If SQL command and >> verb text is converted into a more concise specification for internal >> use, then less memory should be consumed. > > The schema is stored as a parse tree. But it still needs to store the > names of objects (triggers, indexes, tables, columns) in order to look > them up by name in response to various SQL commands. > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
