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.
>
I do not believe any of these things have any impact on stack depth. But
you should probably double-check by running the experiment. Please let us
know if you find me wrong.
>
> 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
