** Changed in: zeitgeist
Status: In Progress = Fix Committed
** Changed in: zeitgeist
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
** Changed in: zeitgeist
Milestone: None = 0.8.0
--
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
https://bugs.launchpad.net/bugs/639737
Title:
Improve insertion times
Status in Zeitgeist Framework:
OK I think the only way we can actually get the insertion time improved
ATM is by using WAL for journaling. However it requires sqlite 3.7 and
once its set to WAL sqlite 3.6 wont be able to access it.
This breaks compatibility with older zeitgeist DBs:
However I think this should be doable if we
** Changed in: zeitgeist
Milestone: 0.6 = 0.7
--
Improve insertion times
https://bugs.launchpad.net/bugs/639737
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitgeist Framework: In Progress
OK I worked out the synchronous = NORMAL pragma for a week now and actually
broke my netbook. What I learned is you have a better chance of messing up your
partition than using synchronous = NORMAL. The deal breaker is the improvement
is not noticeable unless we use journal = WAL
However we are
** Changed in: zeitgeist
Milestone: None = 0.6
--
Improve insertion times
https://bugs.launchpad.net/bugs/639737
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitgeist Framework: In Progress
** Changed in: zeitgeist
Status: Triaged = In Progress
--
Improve insertion times
https://bugs.launchpad.net/bugs/639737
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitgeist Framework: In
Here a more detailed benchmarking:
1) NO CHANGES: ~ 0.12 s
DEBUG:zeitgeist.engine:Inserted 1 events in 0.107999s
DEBUG:zeitgeist.engine:Inserted 1 events in 0.155844s
DEBUG:zeitgeist.engine:Inserted 1 events in 0.128242s
DEBUG:zeitgeist.engine:Inserted 1 events in
Here is a diff...
https://code.edge.launchpad.net/~zeitgeist/zeitgeist/sqlite-insert-improvements/+merge/35701
Here I only set the journal_mode to off since we dont use rollback thus we can
not be harmed AFAIK. It improved my average speed to 0.075 seconds which is
better.
I also benchmarked
** Changed in: zeitgeist
Assignee: (unassigned) = Seif Lotfy (seif)
** Changed in: zeitgeist
Status: New = Triaged
** Changed in: zeitgeist
Importance: Undecided = Wishlist
** Description changed:
We insert pretty slowly with an average of 0.15 seconds for one event on
my
Markus,
Table has exactly 5701 events and need 0.15 seconds per one event for insertion
An empty table needs 0.1 seconds here. The time spent in python is too little
to be mentioned. Sadly its the commit that takes most of the time.
Inserting 10 events in my 5701 events database takes 1.0
I think however our lower boundary is 0.05 seconds since we do commits
after insert events is called, which is a disk write. Now we could avoid
that by first returning the values to the user then commiting... It will
save noticeable time.
Also:
I tried setting journal_mode to WAL
Speed
After reading more into the synchronous mode I found the mode NORMAL
When synchronous is NORMAL (1), the SQLite database engine will still
pause at the most critical moments, but less often than in FULL mode.
There is a very small (though non-zero) chance that a power failure at
just the wrong
What about journal_mode = WAL
I see it being a good candidate too...
On Thu, Sep 16, 2010 at 11:28 PM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@gmail.com wrote:
Everyone be sure to read the details here
http://www.sqlite.org/pragma.html so you can make an informed opinion.
Here's what I
14 matches
Mail list logo
