Re: [sqlite] sqlite in-memory database far too slow in my use case

part of our application. Thanks, Ron > Pavel > > On Sun, Oct 18, 2009 at 2:23 PM, Ron Arts <r...@arts-betel.org> wrote: >> P Kishor schreef: >>> On Sun, Oct 18, 2009 at 10:37 AM, Ron Arts <r...@arts-betel.org> wrote: >>>> Very true Simon, >>&

Re: [sqlite] sqlite in-memory database far too slow in my use case

P Kishor schreef: > On Sun, Oct 18, 2009 at 10:37 AM, Ron Arts <r...@arts-betel.org> wrote: >> Very true Simon, >> >> this has been the fastest way so far and I can do around >> 35 selects/second this way, using prepared statements >> (on my m

Re: [sqlite] sqlite in-memory database far too slow in my use case

into the internal memory structures to gets my record from there. thanks, Ron Simon Slavin schreef: > On 18 Oct 2009, at 8:37am, Ron Arts wrote: > >> Is there a way to bypass the virtual machine altogether and reach >> directly >> into the btree and just retrieve one record by it's o

Re: [sqlite] sqlite in-memory database far too slow in my use case

Pavel Ivanov schreef: >> I use the following queries: >> >> CREATE TABLE company(id INTEGER PRIMARY KEY ASC, name) > > I'm not sure how SQLite treats this table definition but probably > because of your ASC it could decide that id shouldn't be a synonym for > rowid which will make at least

[sqlite] reach into a memory database and retrieve a record by it's oid

or should I try to reach out into btree directly and parse the data directly? I need to speed up record retrieval from a in-memory database, and I know beforehand that 99% of my queries involve retrieving one record by primary integer key. Thanks, Ron Arts

Re: [sqlite] sqlite in-memory database far too slow in my use case (new benchmark inside)

tart transaction at the > beginning and commit/rollback it at the end. > > Tell us if it still doesn't satisfy you. > > > Pavel > > On Sun, Oct 11, 2009 at 4:04 AM, Ron Arts <r...@arts-betel.org> wrote: >> Olaf Schmidt schreef: >>> "Ron Arts" <

Re: [sqlite] sqlite in-memory database far too slow in my use case (new benchmark inside)

ly from > other processes you can place all your inserts in one transaction or > in case of your real application just start transaction at the > beginning and commit/rollback it at the end. > > Tell us if it still doesn't satisfy you. > Pavel, does the cache work for memory datsbase

Re: [sqlite] sqlite in-memory database far too slow in my use case (new benchmark inside)

Alexey Pechnikov schreef: > Hello! > > On Sunday 11 October 2009 12:04:37 Ron Arts wrote: >>CREATE TABLE company(id INTEGER PRIMARY KEY ASC, name) >> >> Then I insert 50 records like this: >> >>INSERT INTO company (id, na

Re: [sqlite] sqlite in-memory database far too slow in my use case (new benchmark inside)

Olaf Schmidt schreef: > "Ron Arts" <r...@arts-betel.org> schrieb im > Newsbeitrag news:4ad10a9e.3040...@arts-betel.org... > >> Here's my new benchmark output: >> >> sqlite3 insert 50 records time: 17.19 secs >> sqlite3 select 50 records t

Re: [sqlite] sqlite in-memory database far too slow in my use case

Jay A. Kreibich schreef: > On Sat, Oct 10, 2009 at 07:24:33PM +0200, Ron Arts scratched on the wall: > >> I'm afraid the process of >> constructing SQL queries / parsing them by sqlite, and >> interpreting the results in my app, multiple times per >> event will be

Re: [sqlite] sqlite in-memory database far too slow in my use case

a hashed index on an existing sqlite memory table this way? Thanks, Ron PS: I *am* impressed by sqlite's speed. Simon Slavin schreef: > On 10 Oct 2009, at 7:04pm, Roger Binns wrote: > >> Ron Arts wrote: >>> So I am wondering if I can drop the glib Hash Tables, and >>>

[sqlite] sqlite in-memory database far too slow in my use case

Hi, I am building a libevent based application that must be able to handle tens of thousands requests per second. Each request needs multiple database lookups. Almost all requests do the lookups on the primary key of the tables only. So far I have been using Hash Tables from the glib2 library.