[EMAIL PROTECTED] wrote:
INTERSECT would give you x=5 AND y=7. For x=5 OR y=7 you want UNION.
Oops, yes of course.
I was thinking of the higher level problem with circles where
intersection could be used to find a small subset of the table that
would then be scanned to locate the
On Wed, 9 May 2007 21:00:46 +0400
Tomash Brechko <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 14:45:33 +, [EMAIL PROTECTED] wrote:
> > You need an R-Tree index to do something like this. The
> > public-domain version of SQLite only supports B-Tree indices.
> > So, no, indices are not
On Wed, May 09, 2007 at 14:45:33 +, [EMAIL PROTECTED] wrote:
> You need an R-Tree index to do something like this. The
> public-domain version of SQLite only supports B-Tree indices.
> So, no, indices are not going to help you here.
Alternatively to R-tree index, you may simply partition the
Dennis Cote <[EMAIL PROTECTED]> wrote:
> >
> > Why full table scan? :/
> > SQLite can takes set (1) of rowid by ex(x) index for
> > "X=5". Then takes another set (2) of rowid by ex(y) for "Y=7".
> > Then SQLite need only to union this two set (1) and (2).
> > Final SQLite should returns rows where
bash wrote:
Why full table scan? :/
SQLite can takes set (1) of rowid by ex(x) index for
"X=5". Then takes another set (2) of rowid by ex(y) for "Y=7".
Then SQLite need only to union this two set (1) and (2).
Final SQLite should returns rows where rowid in (set1 union set2).
I think you
On Wed, 9 May 2007 11:08:26 -0400
"Samuel R. Neff" <[EMAIL PROTECTED]> wrote:
>
> I wonder if it would be beneficial to add an additional where clause which
> can prefilter the data so you only need to perform the full calculation on a
> subset of records.
>
> I haven't done the math, but
On Wed, 09 May 2007 14:45:33 +
[EMAIL PROTECTED] wrote:
> bash <[EMAIL PROTECTED]> wrote:
> >
> > Oh... so this is implementation limitation.
> > Im currently thinking about this table:
> >
> > CREATE TABLE map (
> > x int,
> > y int,
> > name char
> > );
> > CREATE INDEX map_x
[EMAIL PROTECTED] wrote:Note that some client/server database engines (ex:
PostgreSQL
and I think also firebird) will automatically rewrite the
original query into something logically similar to my
second example above. But the query optimizer in SQLite
does not attempt to be quite that
our team building
products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
-Original Message-
From: bash [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 10:33 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] perfomance degradation for expr &
bash <[EMAIL PROTECTED]> wrote:
>
> Oh... so this is implementation limitation.
> Im currently thinking about this table:
>
> CREATE TABLE map (
> x int,
> y int,
> name char
> );
> CREATE INDEX map_x ON map(x);
> CREATE INDEX map_y ON map(y);
>
> And query for it will be
On Wed, 9 May 2007 18:13:07 +0400
Tomash Brechko <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 17:45:52 +0400, bash wrote:
> > > One index per table rule. At first glance it seems like SQLite could
> > > use at least one index for "x=5 OR y=7" case too, but there is no
> > > point in
On Wed, May 09, 2007 at 17:45:52 +0400, bash wrote:
> > One index per table rule. At first glance it seems like SQLite could
> > use at least one index for "x=5 OR y=7" case too, but there is no
> > point in that, as the other part of the OR would require full table
> > scan anyway.
>
> Why full
Tomash Brechko <[EMAIL PROTECTED]> wrote:
>
> sqlite> explain query plan
> ...> SELECT id, n1, n2
> ...> FROM tbl
> ...> WHERE n1 = $I
> ...> UNION
> ...> SELECT id, n1, n2
> ...> FROM tbl
> ...> WHERE n2 = $I
> ...> ORDER BY id DESC;
>
On Wed, 9 May 2007 17:29:29 +0400
Tomash Brechko <[EMAIL PROTECTED]> wrote:
>
> On Wed, May 09, 2007 at 16:32:34 +0400, bash wrote:
> > SELECT * FROM ex1 WHERE x>'abc' AND y>'abc';
> > In this form only one indexes will be used, why not both?
>
> One index per table rule. At first glance it
On Wed, May 09, 2007 at 16:34:57 +0400, bash wrote:
> On Wed, 9 May 2007 14:24:27 +0400
> Tomash Brechko <[EMAIL PROTECTED]> wrote:
> > From http://www.sqlite.org/optoverview.html section 6.0:
> >
> > Each table in the FROM clause of a query can use at most one index...
> >
> > So the first
On Wed, 9 May 2007 12:23:14 +0200
Peter van Dijk <[EMAIL PROTECTED]> wrote:
>
> On 9-mei-2007, at 11:28, bash wrote:
>
> > SELECT type, stamp_id, old_player_id, new_player_id
> > FROM town_log
> > WHERE old_player_id = $ID OR new_player_id = $ID
> > ORDER BY stamp_id DESC;
> >
> > This query
On 9-mei-2007, at 11:28, bash wrote:
SELECT type, stamp_id, old_player_id, new_player_id
FROM town_log
WHERE old_player_id = $ID OR new_player_id = $ID
ORDER BY stamp_id DESC;
This query works really slowly and i don't know why :/
For example, the same result by another QUERY work much
Hello All,
Im using SQLite-3.3.17.
My table is:
CREATE TABLE town_log (
id integer NOT NULL PRIMARY KEY AUTOINCREMENT,
town_id int,
stamp_id int,
old_player_id int,
18 matches
Mail list logo
