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
