2011/4/22 Richard Hipp <d...@sqlite.org>
> I do not believe any of these things have any impact on stack depth. But
> you should probably double-check by running the experiment.
Ok.
> Please let us
> know if you find me wrong.
Yes.
Thank you a lot! Kind regards and happy holidays, Mikael
> On Fri, Apr 22, 2011 at 9:05 AM, Mikael <mikael....@gmail.com> wrote:
>
> > Dear Richard,
> >
> > If by recursion you mean a subselect or alike, then the SQL queries we
> have
> > are of a constant recursion level, generally 0 and 4 or so at max, in any
> > dynamically generated query. Also the depth counted in parentheses of
> WHERE
> > expressions is constant, 5 or so at max.
> >
> > What varies in the dynamic queries is the number of arguments passed to
> IN
> > (), the number of rows passed to INSERT after VALUES, and the size of
> > string
> > constants passde.
> >
>
>
> >
> > By this, I suppose growth of our SQL queries (i.e. because of lots of
> > VALUES, lots of IN () arguments or large string constants) even if up to
> > several megabytes, does not imply use of more stack space?
> >
> > Many thanks,
> > Mikael
> >
> > 2011/4/22 Richard Hipp <d...@sqlite.org>
> >
> > The SQL parser and code generator are recursive. So given arbitrarily
> > > complex SQL, one can use arbitrarily much stack space.
> >
> > If you absolutely must limit your stack size, then you'll want to crank
> > down
> > > your SQLITE_LIMIT_SQL_LENGTH (or at compile-time
> SQLITE_MAX_SQL_LENGTH).
> > > The default value is 1M. Maybe you want to lower this to 10K or 5K.
> > You
> > > should also lower the maximum expression tree depth
> > (SQLITE_LIMIT_EXPR_DEPTH
> > > and SQLITE_MAX_EXPR_DEPTH) from the default 1000 to 10 or 20.
> > > I do not have a formula that relates the maximum SQL length and/or
> > maximum
> > > expression depth to the maximum stack size. But if you run lots of
> > > maximum-length SQL statements with deeply nested expressions using very
> > > short (one-character) constants and column names, measure your maximum
> > stack
> > > usage, then apply a 2x or 3x safety factor, you should be fine.
> >
> >
> >
> >
> > >
> > > On Fri, Apr 22, 2011 at 8:17 AM, Mikael <mikael....@gmail.com> wrote:
> > >
> > >> Aha great.
> > >>
> > >> Is 12KB the amount of stack space needed on any x64 platform upon
> > >> unlimited use (i.e. whatever size and complexity of SQL queries,
> > whatever
> > >> dataset/DB size etc.) with the default configuration/installation?
> > >>
> > >> If not, is there any particular stack size that you would consider a
> > >> 'safe' threshold size to stick with? (I ask because we have some
> dynamic
> > SQL
> > >> query generation, where during our testing we might not ourselves have
> > >> included a query or dataset/DB of the same size or complexity as a
> user
> > >> sometimes would give rise to.)
> > >>
> > >> I'm in an installation that doesn't necessarily have sparse memory
> > >> requirements, it's just that the stack size is fixed and I need to
> > allocate
> > >> many of them, so <=100-200KB would be welcome.
> > >>
> > >> Well ultimately I can check based on runtime experience what stack
> size
> > >> sqlite really uses by padding it with 0xsomething and checking at end
> of
> > >> execution how many of them at the end of the stack are still there.
> The
> > key
> > >> criterion is to somehow prove that it'll always be at least one left.
> > >>
> > >
> > >
> > >> Many thanks,
> > >> Mikael
> > >>
> > >>
> > >> 2011/3/29 Richard Hipp <d...@sqlite.org>
> > >>
> > >>> On Mon, Mar 28, 2011 at 5:25 AM, Mikael <mikael....@gmail.com>
> wrote:
> > >>>
> > >>> > Hi,
> > >>> >
> > >>> > I'm looking at the possibility of using SQLite in an environment
> with
> > a
> > >>> > fixed-size stack, and wish to know, what stack size do I need for
> > >>> SQLite
> > >>> > always to work?
> > >>> >
> > >>>
> > >>> We have heard of people running SQLite in as little as 2K of stack
> > space.
> > >>> Probably there are ways of exceeding that if you really abuse the
> > >>> language,
> > >>> but if it works on your tests, SQLite isn't suddenly going to
> allocate
> > a
> > >>> bunch of extra stack on you in the field.
> > >>>
> > >>> Symbian phones use 12K of stack for SQLite processes.
> > >>>
> > >>>
> > >>> >
> > >>> > Obviously I want it to be as small as possible, as I want as much
> RAM
> > >>> to be
> > >>> > available for other purposes as possible.
> > >>> >
> > >>> > The application uses a constant set of SQL queries that are
> > >>> string-exact,
> > >>> > except for in the case when in some dynamic queries I pass IN (" in
> > >>> > (\"abcd\",\"efghi\",\"jklmn\",\"opqr\"...etc.)"). So the stack size
> > >>> needs
> > >>> > to
> > >>> > hold for those queries, and any dataset sizes (inserting large
> cells,
> > >>> > querying all of long tables with large cells).
> > >>> >
> > >>> > If there would be some kind of runtime checks (i.e. the app dies
> with
> > >>> > printing 'Stack overflow' to stderr on stack overflow), I could
> > always
> > >>> just
> > >>> > increase it up to the level where I ever saw an exception, and add
> > >>> another
> > >>> > 10% for safety.
> > >>> >
> > >>> > Looking forward to your response,
> > >>> >
> > >>> > Kind regards,
> > >>> > Mikael
> > >>> > _______________________________________________
> > >>> > sqlite-users mailing list
> > >>> > sqlite-users@sqlite.org
> > >>> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> D. Richard Hipp
> > >>> d...@sqlite.org
> > >>> _______________________________________________
> > >>> sqlite-users mailing list
> > >>> sqlite-users@sqlite.org
> > >>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > >>>
> > >>
> > >>
> > >
> > >
> > > --
> > > D. Richard Hipp
> > > d...@sqlite.org
> > >
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
