On Wed, Sep 4, 2013 at 3:51 PM, Varadan, Yamini (SCR US) (EXT) <
yamini.varadan@siemens.com> wrote:
>
> But would any one know if there is any kind of synchronization that is
> done between different processes that connect to different sqlite databases
> that might slow down one process when t
Trey Mack wrote:
> I have a fairly large table (10million rows) with a simple INTEGER
> PRIMARY KEY AUTOINCREMENT field.
>
> Executing 'SELECT max(rowid) FROM MyTable' is very fast, as is
> 'SELECT min(rowid) FROM MyTable'.
>
> However, 'SELECT max(rowid) - min(rowid) FROM MyTable' is slow
> (
> I have a fairly large table (10million rows) with a simple INTEGER
> PRIMARY KEY AUTOINCREMENT field.
>
> Executing 'SELECT max(rowid) FROM MyTable' is very fast, as is
> 'SELECT min(rowid) FROM MyTable'.
>
> However, 'SELECT max(rowid) - min(rowid) FROM MyTable' is slow
> (apparently accessi
someone else might give a more technical and scientific explanation,
but my take is that "SELECT n FROM table" is just that -- a row
returned for every row in the table because there is no WHERE clause
constraining the results. "SELECT max() - 1 FROM table" on the
other hand GROUPs the result
Ah, OK, I see that doing 'SELECT 1 FROM MyTable' returns a 1 for every
row, so I can see where the effort is probably going. However, 'SELECT
max(rowid) - 1 FROM MyTable' still only produces one result row
(obviously I'm experimenting with a much smaller database now). Still
need an explanatio
ginal Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 4:10 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Performance Question
Slater, Chad wrote:
> Hello,
>
> I'm having trouble with the performance of one of my queries and my
"sql
&g
Slater, Chad wrote:
Hello,
I'm having trouble with the performance of one of my queries and my "sql
kung fu" is limited. Any help with this problem would be greatly
appreciated
Here's a stripped down version of the tables I'm dealing with:
CREATE TABLE A (
id INTEGER PRIMARY KEY AUTOINCRE
Michael Wohlwend wrote:
But If I do "select data from pictures where (x between high_x and low_x)
and (y between high_y and low_y) then this takes ca. 8 seconds (!) on wince.
Michael,
If you are really writing your between clauses as above with the high
limit first, then they are not doin
Michael Wohlwend wrote:
I made a database of little pictures, which includes x und y coordinates and
Are x and y indexed?
Martin
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
> But If I do "select data from pictures where (x between high_x and low_x)
> and (y between high_y and low_y) then this takes ca. 8 seconds (!) on
> wince.
My sql knowledge may be a little bit rusty and I have really no idea how
sqlite is doing "between" querys. Anyway, once I have learned never
Slater, Chad wrote:
Does the ordering of columns in a table have any impact on performance?
Chad,
Not significantly if your rows have less than a couple of hundred bytes
of data. If they are larger than that they will spill into overflow
page(s). It takes longer to insert and select data
Rob Sciuk wrote:
On Wed, 30 Aug 2006, Mario Frasca wrote:
I understand your concern about legacy programs, but most of us expect
PRIMARY KEY to imply NOT NULL... don't we?
I have to go along with Mario, here. This is a potential show stopper,
I would not be that negative, but a
On Wed, 30 Aug 2006 [EMAIL PROTECTED] wrote:
> > I have to go along with Mario, here. This is a potential show stopper,
>
> Show stopper? Really? The bug has been there for years, literally,
> and nobody has even noticed it until now - despite thousands of users
> and millions and millions of d
Rob Sciuk <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Aug 2006, Mario Frasca wrote:
> > On 2006-0829 13:15:02, [EMAIL PROTECTED] wrote:
> >
> > >> To my surprise (perhaps "horror") I find that SQLite has
> > >> for a very long time allowed NULL values in PRIMARY KEY
> > >> columns. [...]
> >
> > I und
On Wed, 30 Aug 2006, Mario Frasca wrote:
> On 2006-0829 13:15:02, [EMAIL PROTECTED] wrote:
>
> >> To my surprise (perhaps "horror") I find that SQLite has
> >> for a very long time allowed NULL values in PRIMARY KEY
> >> columns. [...]
>
> I understand your concern about legacy programs, but most
On 2006-0829 13:15:02, [EMAIL PROTECTED] wrote:
To my surprise (perhaps "horror") I find that SQLite has
for a very long time allowed NULL values in PRIMARY KEY
columns. [...]
I understand your concern about legacy programs, but most of us expect PRIMARY
KEY to imply NOT NULL... don't we
Kurt Welgehausen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Saying NOT NULL on a PRIMARY KEY is redundant, by the way.
> > --
> > D. Richard Hipp <[EMAIL PROTECTED]>
>
> sqlite> insert into t (k, d) values (null, 'jkl');
> sqlite> select * from t;
> k d
> ---
Mario Frasca wrote:
Kurt Welgehausen wrote:
[...] should I write a bug ticket
about a primary key accepting nulls?
there is already a ticket for that: 518. I reopened it three days ago.
I have right now attached a patch for it. it is quite small and I hope
it fits in the current style.
Kurt Welgehausen wrote:
[EMAIL PROTECTED] wrote:
Saying NOT NULL on a PRIMARY KEY is redundant, by the way.
[...]
Am I missing something, or should I write a bug ticket
about a primary key accepting nulls?
there is already a ticket for that: 518. I reopened it three days ago.
reg
Kurt Welgehausen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>> Saying NOT NULL on a PRIMARY KEY is redundant, by the way.
>> --
>> D. Richard Hipp <[EMAIL PROTECTED]>
>
> **kaw<~/tdpsa>$ sqlite3
> Loading resources from /home/kaw/.sqliterc
> SQLite version 3.3.7
> Enter ".help" for
[EMAIL PROTECTED] wrote:
> Saying NOT NULL on a PRIMARY KEY is redundant, by the way.
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
**kaw<~/tdpsa>$ sqlite3
Loading resources from /home/kaw/.sqliterc
SQLite version 3.3.7
Enter ".help" for instructions
sqlite> .nullvalue '<>'
sqlite> create table t
"Slater, Chad" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Consider the following lookup table definition:
>
> CREATE TABLE foobar (
> id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
> table1_id INTEGER NOT NULL REFERENCES table1,
> table2_id INTEGER NOT NULL REFERENCES table2
> );
>
> Th
> On my PC the following query requires about 53 seconds:
> select * from TABG a, TABB b where (a.S='3' or a.S='12 or...) and
> b.G=a.G order by a.G asc;
>
> (On Oracle with the same scheme and data it requires only 0.4
> seconds.)
In my experience, even though SQLite has very low overhead and
Thanks for the hint, Frank!
It is indeed the Java wrapper which takes its time and it has nothing to
do with SQLite itself.
From the command line the query is done in a blink.
So I have to find a workaround for the Java wrapper since I do not think
there is another one out there.
Thank you all
Thanks! That decreased query time about 3 seconds in the first as well
as the second (!) query.
I suppose that the 50 extra seconds of the first query really have
something to do with the initialization of the DB.
Bo
> On my PC the following query requires about 53 seconds:
>
> select *
Hi,
> I have a question about the performance of my SQLite DB, where the
> db-file has about 20MB and which I use in a Java application via the
> Java wrapper.
First, your timing figures look indeed slower than what I would expect
(using a somewhat similar DB in type and size and a similar select
boysen wrote:
> On my PC the following query requires about 53 seconds:
>
> select * from TABG a, TABB b
> where (a.S='3' or a.S='12 or...) and b.G=a.G order by a.G asc;
>
> On Oracle with the same scheme and data it requires only 0.4 seconds.
>
SQLite does not optimize OR terms in a WHERE
Kei wrote:
> Hi all,
>
> I have one performance question about select all and select all with limit
> and offset. I do the test for measuring the time usage of the following
> select statement.
>
> Task 1. select * from tablename order by name Task 2. select * from table
> name order by name limit
28 matches
Mail list logo
