On Thu, 2 May 2013 16:58:01 +0200
"Jan Slodicka" wrote:
> Hi Dan
>
> > What are your settings for pragmas "cache_size", "journal_mode" and
> > "synchronous"?
>
> cache_size/synchronous - default values
>
> Don't remember, which journal_mode was used for testing. Should be
> WAL, but I might ha
Hi Dan
> What are your settings for pragmas "cache_size", "journal_mode" and
> "synchronous"?
cache_size/synchronous - default values
Don't remember, which journal_mode was used for testing. Should be WAL, but I
might have been lazy to write needed code.
The source code was meanwhile modified,
On 2 May 2013, at 2:57pm, Jan Slodicka wrote:
> LIKE is used at the moment, but it has its perf limits as well. To prove it,
> here is a desktop benchmark:
>
> Desktop: W7, x64, Intel i5, 2.4 GHz
> 116 MB email table containing 1 html-formatted emails.
> SELECT ... LIKE...'%xxx%'... command
On Thu, 2 May 2013 11:16:06 +0200
"Jan Slodicka" wrote:
> I was testing various ways how to interrupt rebuilding of an FTS
> index. Ability to abort is vital as the app is running on a
> smartphone and has to meet responsivity requirements.
>
> Here is what SQLite offers (AFAIK):
> - Progress ha
Hi Simon.
> I have much love for FTS but it chews up storage space, processing power,
and therefore battery life, something fierce. You may end up with a working
app but your users will find it reduces their battery life to an hour.
Sounds unbelievable. Can you bring some example, please?
In th
On 2 May 2013, at 10:16am, "Jan Slodicka" wrote:
> I was testing various ways how to interrupt rebuilding of an FTS index.
> Ability to abort is vital as the app is running on a smartphone and has to
> meet responsivity requirements.
Sorry, I don't know an answer to your question, but I do have
I was testing various ways how to interrupt rebuilding of an FTS index.
Ability to abort is vital as the app is running on a smartphone and has to
meet responsivity requirements.
Here is what SQLite offers (AFAIK):
- Progress handler (with low nOps value): Relatively good with only
occasional long
Would forking another process as a worker process be acceptable, then
in your main message loop wait for some IPC signal saying it is done?
Unless you are doing this on some extremely lightweight OS / monitor
that doesn't implement the concept of time-sharing, I can't see how
this would be hard to
On , Dan wrote:
>> My doubt is the following: if from the progress callback (set with
>> sqlite3_progress_handler) I return non 0 and therefore I get
>> SQLITE_INTERRUPT from the call to sqlite3_step, is the sqlite3_stmt
>> object still in a valid state and will the query resume normally if I
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
João Eiras wrote:
> My doubt is the following: if from the progress callback (set with
> sqlite3_progress_handler)
Why don't you call the main message loop from within the progress
handler callback?
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG
On Jun 22, 2009, at 6:10 PM, João Eiras wrote:
> Hello!
>
> I developing an single threaded app (pre-established fact, can't
> change this), and to keep the UI usable, when sqlite is executing,
> between multiple calls to sqlite3_step, I just break away and let the
> main message loop run a bit m
Hello!
I developing an single threaded app (pre-established fact, can't
change this), and to keep the UI usable, when sqlite is executing,
between multiple calls to sqlite3_step, I just break away and let the
main message loop run a bit more. If the query i executing has an
"order by" clause, then
12 matches
Mail list logo
