> But I sqlite can still check the number of db connections open
Even though as Michael have shown this is possible (with guaranteed
results only when run as root) it will still have races. Because if
you see only one process accessing database file at the end of
transaction and only one process a
qlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Richard Hipp [d...@sqlite.org]
Sent: Wednesday, August 10, 2011 1:27 PM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] In memory v/s tmpfs
On Wed, Aug 10, 2011 at 2:13 PM, Sreekumar TP wrote:
> But
Oh Yes. I missed that point !
On Wed, Aug 10, 2011 at 11:57 PM, Richard Hipp wrote:
> On Wed, Aug 10, 2011 at 2:13 PM, Sreekumar TP >wrote:
>
> > But I sqlite can still check the number of db connections open
> >
>
>
> No it cannot.
>
> In unix, there is no way for one process to know whether o
On Wed, Aug 10, 2011 at 2:13 PM, Sreekumar TP wrote:
> But I sqlite can still check the number of db connections open
>
No it cannot.
In unix, there is no way for one process to know whether or not another
process has a particular file open. And if there is a mechanism to do that
in windows, I
Ok.. But I sqlite can still check the number of db connections open and
optimise the checking=> as long as there is only one writer, do not check
for hot journals.
Can a database have two connections opened with two different journal modes
?
On Wed, Aug 10, 2011 at 11:35 PM, Pavel Ivanov wrote:
> If you have one reader and many writers, consider PRAGMA journal_mode=WAL;
Richard meant "one writer and many readers" of course.
>> If the other process opens the db connection as read_only, will the hot
>> journal check be still done (during queries operations of the second
>> process)?
>>
>
On Wed, Aug 10, 2011 at 1:35 PM, Sreekumar TP wrote:
> Ok, its getting a bit clear.
> If there is only one process that is writing to the database, but has more
> than one process that reads the database, the locking mode can still be
> exclusive ?
>
PRAGMA locking_mode=EXCLUSIVE; means "exclus
Ok, its getting a bit clear.
If there is only one process that is writing to the database, but has more
than one process that reads the database, the locking mode can still be
exclusive ?
If the other process opens the db connection as read_only, will the hot
journal check be still done (during qu
On Wed, Aug 10, 2011 at 1:09 PM, Simon Slavin wrote:
>
> On 10 Aug 2011, at 6:01pm, Sreekumar TP wrote:
>
> > Thanks for the explanation. The journal mode was OFF which means there
> is
> > no journal file created. So why is it the check still performed ?
>
> Because the journal mode might have
The journal mode was always OFF when the code executes. The db was/is never
opened with a journal.
I havent analysed when exactly these calls are made, but definitely, it
quite a lot..
On Wed, Aug 10, 2011 at 10:39 PM, Simon Slavin wrote:
>
> On 10 Aug 2011, at 6:01pm, Sreekumar TP wrote:
>
> >
On 10 Aug 2011, at 6:01pm, Sreekumar TP wrote:
> Thanks for the explanation. The journal mode was OFF which means there is
> no journal file created. So why is it the check still performed ?
Because the journal mode might have been 'ON' the last time that database was
used.
> On Wed, Aug 10,
1189370 read
> > >
> > > 8.160.096124 0414624 gettimeofday
> > > 2.550.033750 8 fdatasync
> > >
> > > On Tue, Aug 9, 2011 at 7:34 PM, Pavel Ivanov
> > wrote:
> > >
&g
;> > Journal mode is WAL
> >>
> >> I believe in-memory database can't have journal mode WAL. So you
> >> compare completely different settings.
> >>
> >>
> >> Pavel
> >>
> >>
> >> On Tue, Aug 9, 2011 at 5:15
>
>> On Tue, Aug 9, 2011 at 5:15 AM, wrote:
>> >
>> > Journal mode is WAL
>> >
>> >
>> > --Original Message--
>> > From: Roger Binns
>> > Sender: sqlite-users-boun...@sqlite.org
>> > To: General Discussion of SQL
gt; Sender: sqlite-users-boun...@sqlite.org
> > To: General Discussion of SQLite Database
> > ReplyTo: General Discussion of SQLite Database
> > Subject: Re: [sqlite] In memory v/s tmpfs
> > Sent: Aug 9, 2011 2:42 PM
> >
> > -BEGIN PGP SIGNED MESSAGE-
> &
lite-users-boun...@sqlite.org
> To: General Discussion of SQLite Database
> ReplyTo: General Discussion of SQLite Database
> Subject: Re: [sqlite] In memory v/s tmpfs
> Sent: Aug 9, 2011 2:42 PM
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/08/2011 06:3
Journal mode is WAL
--Original Message--
From: Roger Binns
Sender: sqlite-users-boun...@sqlite.org
To: General Discussion of SQLite Database
ReplyTo: General Discussion of SQLite Database
Subject: Re: [sqlite] In memory v/s tmpfs
Sent: Aug 9, 2011 2:42 PM
-BEGIN PGP SIGNED MESSAGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/08/2011 06:34 PM, sreekumar...@gmail.com wrote:
> From the point of view of performance, I expected similar performance , tmpfs
> being a little slower due to filesystem overhead. However, the operations on
> tmpfs was much slower than expected
> What could be a possible explanation for this behaviour?
> One difference int configurations is that the sqlite lib is built for
> multithreading in the tmpfs scenario.
Could it be an overhead of mutexes?
Make tests with the same SQLite library. Run test with tmpfs using
strace to see if files
HI,
I performed an experiment where I do db operations on an in-memory database and
compared it with the results from same operations on a database in tmpfs.(Same
db structure,records etc)
>From the point of view of performance, I expected similar performance , tmpfs
>being a little slower due
20 matches
Mail list logo
