>This problem has been coming up with more and more frequency.
>I need to either figure out a solution or at least write up
>some official documentation on it.
I think that table partitioning as I purposed about a month ago would be
a solution if data is of nature, that it can be partitioned b
Hello,
On Wed, Apr 12, 2006 at 09:02:34PM -0400, [EMAIL PROTECTED] wrote:
> Jerome Alet <[EMAIL PROTECTED]> wrote:
> >
> > SQLite is way faster than the two other databases at least when the
> > number of records is reasonable, but when the database reaches
> > around 300 Mb which is something li
> Thanks for the link. But InnoDB uses the same basic architecture
> as SQLite. So this does not explain why performance drops off
> on SQLite but not on InnoDB.
>
> Still looking
Does SQLite perform this InnoDB optimization?
"Dirty (changed) database pages are not immediately sent to the
Joe Wilson <[EMAIL PROTECTED]> wrote:
> http://en.wikipedia.org/wiki/InnoDB
>
> --- [EMAIL PROTECTED] wrote:
> > I'm really curious to know how PostgreSQL and MySQL avoid this
> > thrashing problem. Does anybody have any insight on this?
>
Thanks for the link. But InnoDB uses the same basic ar
Nick Brown <[EMAIL PROTECTED]> wrote:
> On Saturday 25 March 2006 13:33:47 someone scribbled:
> > > > > types3-1.3...
> > > > > Expected: [wideInt integer]
> > > > > Got: [int integer]
> >
> > The types3-1.3 error occurs because on ia64, a regular
> > old integer is sufficient to hold the val
> I'm really curious to know how PostgreSQL and MySQL avoid this
> thrashing problem. Does anybody have any insight on this?
MySQL (in the InnoDB engine) reduces thrashing through clustering of data in
(roughly) primary key order. This helps if you obtain data with similar
primary keys. It does
Brian Johnson
<[EMAIL PROTECTED]> wrote:
Here is example of what I'm trying to do in the bash script:
sqlite3 db.dat "BEGIN; \
UPDATE table1 SET name='O'Neil' WHERE person_id=2 \
COMMIT;"
there are more UPDATE lines or I wouldn't bother with the BEGIN; and
COMMIT; .. but the real problem is tha
Two apostrophes in a row.
SET name='O''Neil'
You can also use double quotes, as long as you know your name value won't
ever contain them:
SET name="O'Neil"
Escaping those further so the bash shell doesn't chew them is left as an
exercise to the reader.
- Pam
On 4/12/06, Brian Johnson <[EMAIL
I'm trying to script a multi-line command and the apostrophes are driving me
nuts .. I can't get the right formatting
Here is example of what I'm trying to do in the bash script:
sqlite3 db.dat "BEGIN; \
UPDATE table1 SET name='O'Neil' WHERE person_id=2 \
COMMIT;"
there are more UPDATE lines or
http://en.wikipedia.org/wiki/InnoDB
--- [EMAIL PROTECTED] wrote:
> I'm really curious to know how PostgreSQL and MySQL avoid this
> thrashing problem. Does anybody have any insight on this?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the bes
On Saturday 25 March 2006 13:33:47 someone scribbled:
> > > > types3-1.3...
> > > > Expected: [wideInt integer]
> > > > Got: [int integer]
>
> The types3-1.3 error occurs because on ia64, a regular
> old integer is sufficient to hold the value whereas on
> an ix86 machine, a long long int is
On 4/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I'm really curious to know how PostgreSQL and MySQL avoid this
> thrashing problem. Does anybody have any insight on this?
The big databases do it by moving the database code to a separate
server machine.
It has it's own cache and doesn
<[EMAIL PROTECTED]> wrote:
> The problem (I suspect) is that you have an index on Table3.
> As you insert to records into Table3, those record go at the
> end, which is very efficient. But the index entries have to
> be inserted in index order, which means they get scattered
> out all through the
[EMAIL PROTECTED] wrote:
> Bill KING <[EMAIL PROTECTED]> wrote:
>
>
> The current parser in SQLite is UTF-8 only. So when you use
> sqlite3_prepare16() the first thing it does is translate you
> input SQL into UTF-8 then pass it off to sqlite3_prepare().
> There is no easy fix for this - I am n
Jerome Alet <[EMAIL PROTECTED]> wrote:
>
> SQLite is way faster than the two other databases at least when the
> number of records is reasonable, but when the database reaches
> around 300 Mb which is something like 400 records in Table3,
> it slows down dramatically (in fact the slowdown is p
Bill KING <[EMAIL PROTECTED]> wrote:
> Okay, background is we're working on embeded linux for mobile
> phones/pdas. Being worldwide, it needs to be UTF-16 (for obvious
> reasons, especially with our main market being china). Lately, I've been
> working on performance. (The section I'm using uses a
Okay, background is we're working on embeded linux for mobile
phones/pdas. Being worldwide, it needs to be UTF-16 (for obvious
reasons, especially with our main market being china). Lately, I've been
working on performance. (The section I'm using uses a database as the
backing store for metadata on
Jerome Alet <[EMAIL PROTECTED]> wrote:
>
> SQLite is way faster than the two other databases at least when the
> number of records is reasonable, but when the database reaches
> around 300 Mb which is something like 400 records in Table3,
> it slows down dramatically (in fact the slowdown is p
On 4/12/06, Jerome Alet <[EMAIL PROTECTED]> wrote:
> However any of these command line tools MUST be interruptible
> with Ctrl+C (for example) by the user who launched them, for
> example because of a typo in the command, or something like that.
If you are using SQLite directly, you might want to
What you're seeing is the effect of file system caching buffers running out
on the operating system (used for write caching, caching of indices, caching
of the transaction log file etc.) and the PC having to go to disk.
We had this exact same issue with regards to our stock price databases. All
l
Arun Bhalla <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I performed a quick benchmark of three different string indexing schemes
> for SQLite3.
>
> * Scheme 0 = indexing on the string field
> * Scheme 1 = indexing on the MD5 sum (as text in hexadecimal
> representation) of the string
> * Scheme
I forgot to mention -- I was using SQLite 3.3.4.
Arun Bhalla wrote:
Hi,
I performed a quick benchmark of three different string indexing schemes
for SQLite3.
* Scheme 0 = indexing on the string field
* Scheme 1 = indexing on the MD5 sum (as text in hexadecimal
representation) of the strin
Hi,
I performed a quick benchmark of three different string indexing schemes
for SQLite3.
* Scheme 0 = indexing on the string field
* Scheme 1 = indexing on the MD5 sum (as text in hexadecimal
representation) of the string
* Scheme 2 = indexing on the high 64 bits of the MD5 sum (as int) o
On Wed, Apr 12, 2006 at 04:27:29PM -0700, Will Leshner wrote:
> On 4/12/06, Jerome Alet <[EMAIL PROTECTED]> wrote:
>
> > All the test program does in the mainloop is a bunch of INSERT
> > queries all on the same table, but all INSERTS (millions of them)
> > are done within a single SQL transaction
On 4/12/06, Jerome Alet <[EMAIL PROTECTED]> wrote:
> All the test program does in the mainloop is a bunch of INSERT
> queries all on the same table, but all INSERTS (millions of them)
> are done within a single SQL transaction.
Are you doing millions of inserts in one transaction?
Hi there,
I've added support for SQLite 3 in my PyKota print accounting software.
This software supports PostgreSQL, MySQL and SQLite as its database
backend, and so it's easy to do some benchmarking, since in all cases
the very same SQL queries are executed (I know this **may not** be
the optima
"Brian Johnson" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > "Brian Johnson" <[EMAIL PROTECTED]> wrote:
> > > Why does a INTEGER PRIMARY KEY field autoincrement when inserting a NULL
> > > into
> > > that field as per http://www.sqlite.org/faq.html#q1 and a field defined
> > > as
[EMAIL PROTECTED] wrote:
>
> "Brian Johnson" <[EMAIL PROTECTED]> wrote:
> > Why does a INTEGER PRIMARY KEY field autoincrement when inserting a NULL
> > into
> > that field as per http://www.sqlite.org/faq.html#q1 and a field defined as
> > int
> > primary key not work the same way?
>
> Because y
"Brian Johnson" <[EMAIL PROTECTED]> wrote:
> I have a few questions about autoincrement and RowID that I couldn't google an
> answer
>
> I have a database for hardware with limited ram (and flash ram) so I'd like to
> use as little ram as possible.
>
> Is there any difference between the hidden f
I have a few questions about autoincrement and RowID that I couldn't google an
answer
I have a database for hardware with limited ram (and flash ram) so I'd like to
use as little ram as possible.
Is there any difference between the hidden field rowid and a field defined as
INTEGER PRIMARY KEY?
I
On 4/11/06, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Nuno Lucas wrote:
> >
> >..., but it should work the same.
> >
> Famous last words. :-)
>
Hehe, yes.
That's why I thought it was worth writing it ;-)
Best regards,
~Nuno Lucas
Steve Bergman wrote:
When I moved this change to the server which is actually going to be
running this (which was Sqlite 3.1.x) the query was still slow even
with the index available. However, upgrading it to 3.3.3 and
ANALYZE'ing it fixed the problem there, as well.
The index is most eff
Dennis Cote wrote:
The fast query does a table scan of the Timesheet table looking for
records that are between the specified dates. For each such record, it
looks up the client, project, and employee records by matching the
timesheet fields to the primary key of those tables. These extende
Steve Bergman wrote:
None of the tables have many records. Timesheet has about 4000.
employee has about 15. Client has about 100. project has about 200.
The "Fast query, below, executes in about a second.
But I'm curious what is "wrong" with the "Slow query".
Schema and EXPLAIN results ar
Richard,
Thanks for the response.
I do apologise, I made a mistake in my original mail - I have a macro
which allows me to easily switch between using 2 and 3 in my apps:
For SQLite 3:
# define sqlite_set_result_string(a,b,c)
sqlite3_result_text(a,b,c,NULL)
This just allows me to not change
"Drew, Stephen" <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I have written a function to replicate the Oracle DECODE function, which
> I register whenever I open a SQLite3 (3.2.6) connection (see bottom of
> email).
>
> However it seems that certain decodes fail due to corrupted data. I
> have
Thank you, so much, Mr. Lucas! Upgrading sqlite solved
my problem! I had been stuck on that one for over a
month! What a relief!
Thanks again!!
Siobhan
--- Nuno Lucas <[EMAIL PROTECTED]> wrote:
> On 4/11/06, Siobhan Kivler <[EMAIL PROTECTED]>
> wrote:
> > Thank you very much for replying. I wa
Thanks, Joe and Rao for your replies. Yes, 3.2.3 was the first release
with ANALYZE. Rao, are you thinking of "EXPLAIN"? ;-)
I'm using the Python ORM "SQLObject" in my current project. It is
generating the "Slow query" below which is taking about 20 seconds to
execute.
None of the tables
Hello all,
I have written a function to replicate the Oracle DECODE function, which
I register whenever I open a SQLite3 (3.2.6) connection (see bottom of
email).
However it seems that certain decodes fail due to corrupted data. I
have stepped through my code and seen that the value is correct
Phuah Yee Keat wrote:
Is there any specific reasons that "sqlite3 -version" is returning 1
instead of 0?
As I understand, most of the tools return 0 for a -version or
--version query.
I don't think there is any reason for this. You should file a bug report
at http://www.sqlite.org/cvstrac/
Hi,
Is there any specific reasons that "sqlite3 -version" is returning 1
instead of 0?
I am using sqlite3 -version to store the sqlite3 version in one of my
build scripts, inside MAKEFILE, and I have to do "-sqlite3 -version" to
get make to ignore the error.
As I understand, most of the to
41 matches
Mail list logo