On 10/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This is true of SQLite because isolation in SQLite
> is "SERIALIZABLE". This is the highest level of isolate
> provided by SQL. Most client/server database engines
> by default implement "READ COMMITTED". The value of
> "balance"
Richard:
Actually No, process A will not acquire the reserved lock. It failes returning
a sqlite_busy, and must perform a rollback. Even if Process B commits. Process
A will get a sqlite_busy, forcing you to rollback.
In order for the application to be correct the entire transaction must be
[Default] On Thu, 25 Oct 2007 21:04:44 -0700 (PDT), Vijaya
Lakshmi <[EMAIL PROTECTED]> wrote:
>Hi all,
> I need small help regarding software .Acutually my application was
>developed in SQLite2.1 by some body now i need SQLite2.1 version.Actually I
>found SQLite3 version but by using this
Given Johns suggestion of faster disk:
a 15k disk should get 125 commits /second.
a 10k disk should get 83 commits/ second
a 7200 gets 60 commits/second
I wonder what the impact of the varying filesystem configurations would have on
sqlite commit performance ?
Say reiser, ext3
That makes sense given SERIALIZABLE transactions.
The entire trasaction will require rollback since it gets a sqlite_busy, Not
just the update. This also has the effect of invalidating the data selected
within the transaction that performs the rollback.
Oracle defaults to Read Committed. But
Sent a Commit every 1000 records and now I have 1600-2000 inserts
per second.
Still don't know what was wrong first, but it's working now.
Thanks everybody!
On 26 Oct 2007 at 17:02, [EMAIL PROTECTED] wrote:
> "Fabio Durieux Lopes" <[EMAIL PROTECTED]> wrote:
> >
> >
Not sure, but 10K or 15K.
On 26 Oct 2007 at 12:39, John Stanton wrote:
> What are the rotational speeds of the disks?
>
> Fabio Durieux Lopes wrote:
> > Hmmm, let me see, both machines are DELL machines and with very
> > similar specs. If any, I'd say that the new hardware should
What are the rotational speeds of the disks?
Fabio Durieux Lopes wrote:
Hmmm, let me see, both machines are DELL machines and with very
similar specs. If any, I'd say that the new hardware should run
faster. And the performance problem is way slower. GW0 runs for 8
minutes, while GW2 was
An obvious improvement is to use 15,000 RPM disks.
Fabio Durieux Lopes wrote:
No, it is definitely local.
Does anyone know if theres any kind of hardware/os spec that may
influence sqlite performance?
On 26 Oct 2007 at 16:53, Renaud HUILLET wrote:
My 2 cents:
Could it be that
Hmm, GW0 (RHE3, the fast one) does 190-300 inserts/second. GW2 does
around 15 inserts/second.
I'm gonna try to commit every 1000 records and I'll be back with
results.
Thanks!
On 26 Oct 2007 at 17:02, [EMAIL PROTECTED] wrote:
> "Fabio Durieux Lopes" <[EMAIL
Hmmm, let me see, both machines are DELL machines and with very
similar specs. If any, I'd say that the new hardware should run
faster. And the performance problem is way slower. GW0 runs for 8
minutes, while GW2 was running it for 30 minutes when I decided to
interrupt it.
I
"Fabio Durieux Lopes" <[EMAIL PROTECTED]> wrote:
>
> I've seen people saying one should use transactions
> [B]ut my question is: If I'm using the same binary on
> both computers shouldn't I get similar performances on
> both computers?
>
INSERT is very fast in SQLite. What is slow is not
Your experiment gives you the answer to your question. You are running
the same software and therefore you are measuring the differences in the
disk and disk controller function between the two platforms. Sqlite's
ACID capability is very much dependent upon the disk hardware.
Fabio Durieux
No, it is definitely local.
Does anyone know if theres any kind of hardware/os spec that may
influence sqlite performance?
On 26 Oct 2007 at 16:53, Renaud HUILLET wrote:
>
> My 2 cents:
> Could it be that on the new machine, your sqlite file is no longer local ?
> If you
My 2 cents:
Could it be that on the new machine, your sqlite file is no longer local ?
If you access it through NFS, you get some overhead .
Renaud
> From: [EMAIL PROTECTED]
> To: sqlite-users@sqlite.org
> Date: Fri, 26 Oct 2007 14:32:37 -0200
> Subject: [sqlite] Very poor performance on an
Ok, I have a performance problem with SQLITE. First of all I'd like
to say that Ihave searched the archives and other sites too but
didn't find a problem like mine.
Recently I made a software that got records from a remote ORACLE
database, created a local SQLITE
Ken <[EMAIL PROTECTED]> wrote:
>
> BEGIN TRANSACTION;
> SELECT balance FROM accounts WHERE accountId = '123-45-6789';
> UPDATE accounts SET balance =
> WHERE accountId = '123-45-6789';
> COMMIT;
>
> This is a comman and naive assumption that the balance selected
> will
Richard Klein <[EMAIL PROTECTED]> wrote: Dan Kennedy wrote:
> On Wed, 2007-10-24 at 21:38 -0700, Richard Klein wrote:
>> As I was thinking about the locking mechanism in SQLite 3,
>> it occurred to me that the following race condition could
>> occur.
>>
>> Imagine a joint bank account with a
PTHREAD_PROCESS_SHARED
mutex type for system-wide scope is equivalent to the
USYNC_PROCESS flag to mutex_init() in the Solaris
API (see below). The object
initialized with this attribute must be allocated in
memory shared between processes, either in System V
Igor Tandetnik <[EMAIL PROTECTED]> wrote:
Ingar Steinsland
<[EMAIL PROTECTED]>
wrote:
I want to open a communication channel in program A. This program
will, based upon input from
the communication channel, launch either program B or C. Fine, no
problem. But I want to let
the communication stay
Ingar Steinsland <[EMAIL PROTECTED]> wrote:
I want to open a communication channel in program A. This program
will, based upon input from
the communication channel, launch either program B or C. Fine, no
problem. But I want to let
the communication stay open and also make it available for
21 matches
Mail list logo
