[sqlite] SQL statements not captured by sqlite_trace or sqlite_profile?

Hi, I am trying to use sqlite_trace and sqlite_profile to trace what SQL statements have been executed. In the callback function of sqlite_trace/profile I simply print out the SQL statement which triggers the callback. And in sqlite_open_v2() I have: sqlite3_trace(*ppDb, print_sql_callback,

[sqlite] Is there a way to measure query time in sqlite at runtime?

I want to measure the execution time of each sql statement in sqlite. I understand in sqlite shell you could just do .timer on, but I am wondering how to do it in a pogrammerable way so that I could know how much time a sql statement takes when applications are accessing the database at real

Re: [sqlite] light weight write barriers

On Thu, Nov 15, 2012 at 10:29 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 15 Nov 2012, at 4:14pm, 杨苏立 Yang Su Li <s...@cs.wisc.edu> wrote: > > > 1. fsync actually does two things at the same time: ordering writes (in a > > barrier-like manner),

Re: [sqlite] light weight write barriers

On Thu, Nov 15, 2012 at 6:07 AM, David Lang wrote: > On Wed, 14 Nov 2012, Vladislav Bolkhovitin wrote: > > Nico Williams, on 11/13/2012 02:13 PM wrote: >> >>> declaring groups of internally-unordered writes where the groups are >>> ordered with respect to each other... is

Re: [sqlite] light weight write barriers

On Fri, Oct 26, 2012 at 8:54 PM, Vladislav Bolkhovitin wrote: > > Theodore Ts'o, on 10/25/2012 01:14 AM wrote: > >> On Tue, Oct 23, 2012 at 03:53:11PM -0400, Vladislav Bolkhovitin wrote: >> >>> Yes, SCSI has full support for ordered/simple commands designed >>> exactly for that

Re: [sqlite] light weight write barriers

I am not quite whether I should ask this question here, but in terms of light weight barrier/fsync, could anyone tell me why the device driver / OS provide the barrier interface other than some other abstractions anyway? I am sorry if this sounds like a stupid questions or it has been discussed