seeking sqlite3_progress_handler advice

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

seeking sqlite3_progress_handler advice

Will Leshner-2
I'm wondering if anybody has any suggestions for a good number to  
pass as the second argument to sqlite3_progress_handler to indicate  
how many opcodes to wait before the progress handler is called. I  
realize it depends on a great many factors, so it is probably  
impossible to come up with a good general number. But I'm thinking  
I'd like to keep the progress handler from getting called at all for  
most typically short queries/commands and only have it get called for  
operations that are going to take longish amount of time. I am also  
planning to keep track of a time-based progress update interval in  
the progress handler, so I am not really depending on the opcode  
count. I'd just like to keep the progress handler from getting called  
too often.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: seeking sqlite3_progress_handler advice

D. Richard Hipp
Will Leshner <[hidden email]> wrote:
> I'm wondering if anybody has any suggestions for a good number to  
> pass as the second argument to sqlite3_progress_handler to indicate  
> how many opcodes to wait before the progress handler is called.

Figure 10 to 20 microseconds per opcode.  I'd say around 100.

Please note that the counter resets with each call to sqlite3_step().
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: seeking sqlite3_progress_handler advice

Will Leshner-2

On Oct 6, 2005, at 10:57 AM, [hidden email] wrote:

> Figure 10 to 20 microseconds per opcode.  I'd say around 100.
>

Thanks. That makes sense.

> Please note that the counter resets with each call to sqlite3_step().

That is very good to know. Does that mean that if I set the count too  
high, the progress handler might never get called?
Reply | Threaded
Open this post in threaded view
|

Re: seeking sqlite3_progress_handler advice

D. Richard Hipp
In reply to this post by Will Leshner-2
Will Leshner <[hidden email]> wrote:
> On Oct 6, 2005, at 10:57 AM, [hidden email] wrote:
>
> > Please note that the counter resets with each call to sqlite3_step().
>
> That is very good to know. Does that mean that if I set the count too  
> high, the progress handler might never get called?

That depends on your SQL statements.  Some queries can run a long
time without returning from sqlite3_step().  

The idea is that you should all your "update" routine before and
after sqlite3_step() as well as from the progress callback.
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: seeking sqlite3_progress_handler advice

Christian Smith
In reply to this post by Will Leshner-2
On Thu, 6 Oct 2005, Will Leshner wrote:

>
>On Oct 6, 2005, at 10:57 AM, [hidden email] wrote:
>
>> Figure 10 to 20 microseconds per opcode.  I'd say around 100.
>>
>
>Thanks. That makes sense.
>
>> Please note that the counter resets with each call to sqlite3_step().
>
>That is very good to know. Does that mean that if I set the count too
>high, the progress handler might never get called?
>

You can call the progress handler yourself after sqlite3_step returns, as
for selects, you'll return for each row.

I think it's more aimed at big updates, index building, the sort of thing
that does not return results and takes a long time.

Christian

--
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \