On Tue, 2005-08-02 at 17:36 +0200, djm wrote:
> Hello,
>
> Thanks very much for the detailed and helpful response. Ill certainly
> have a look at the book you receommended.. thanks for the tip.
>
> Sunday, July 31, 2005, 4:47:11 PM, you wrote:
>
> > As a result, any piece of software that
On 8/2/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 00:05 +0200, Martijn Voncken wrote:
> > I'm using pysqlite2,compiled against sqlite 3.2.1
> > I thought that IN uses an index.
> >
>
> Versions 3.2.2 and earlier only use IN in an index if
> the column on the left of
On 8/3/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 00:05 +0200, Martijn Voncken wrote:
> > I'm using pysqlite2,compiled against sqlite 3.2.1
> > I thought that IN uses an index.
> >
>
> Versions 3.2.2 and earlier only use IN in an index if
> the column on the left of
On Wed, 2005-08-03 at 00:05 +0200, Martijn Voncken wrote:
> I'm using pysqlite2,compiled against sqlite 3.2.1
> I thought that IN uses an index.
>
Versions 3.2.2 and earlier only use IN in an index if
the column on the left of the IN operator is the
left-most column in the index. This
BETWEEN doesn't use an index either. I have yet to get an
explaination for either of them :(
On 8/2/05, Martijn Voncken <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm using pysqlite2,compiled against sqlite 3.2.1
> I thought that IN uses an index.
>
> Quote from :
>
Hi,
I'm using pysqlite2,compiled against sqlite 3.2.1
I thought that IN uses an index.
Quote from : http://www.mail-archive.com/sqlite-users%40sqlite.org/msg09004.html
>Indices are not currently used unless you say:
> SELECT * FROM a WHERE f1 IN (5,11);
But "IN" does not use an index in my
Dear Kervin,
> What does the the 'where' command say?
(See the original start of the thread for the whole kaboodle), but
here's the offending select:
select
r.kp,
substr(r.kp,1,13) as records,
r.result2,
r.result4,
r.result12,
min(1,(r.arecords2/100)) as ap2,
Dear Richard,
> Patches to fix ticket #1346 are available at
> http://www.sqlite.org/cvstrac/chngview?cn=2573
> Please try adding these patches and see if they do not
> fix the problem in the multi-threaded application.
Some results. (and bear in mind that I'm not sure that
my particular core
Where is the downloadable documentation? It was supposed to have been in
cluded with the tarball sources, but I don't see it.
Thanks everyone for your response.
Dennis, that works great!
Jay, I think I presume you meant (x >= 'a'). This works great too!
Thank you again!
On 8/2/05, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Thomas Briggs wrote:
>
> >
> >
> >
> >
> >>However if I use something like:
> >>select * from
On Tue, 2005-08-02 at 09:30 -0400, D. Richard Hipp wrote:
> On Mon, 2005-08-01 at 22:04 +0200, Jens Miltner wrote:
> > we get an assertion (no crash here, though) in btree.c
> > and the backtrace looks similar to the one scunacc provided, which
> > made me think the two might be related...
>
Thomas Briggs wrote:
However if I use something like:
select * from myTable where column2!='';
(Takes a long time to return).
I guess because the column in that row isn't indexed? Any
alternatives?
I don't believe that indices can be used to satisfy != conditions, so
even if
did you try this instead of not equal?
(x >= 'abc' AND x < 'abd').
> However if I use something like:
> select * from myTable where column2!='';
> (Takes a long time to return).
>
> I guess because the column in that row isn't indexed? Any
> alternatives?
I don't believe that indices can be used to satisfy != conditions, so
even if the column is indexed,
On Mon, 2005-08-01 at 22:04 +0200, Jens Miltner wrote:
> we get an assertion (no crash here, though) in btree.c
> and the backtrace looks similar to the one scunacc provided, which
> made me think the two might be related...
I am able to reproduce the bug described in ticket #1346.
It looks
Sorry, I read your trace wrong, thought the
debugger was complaining.
What does the the 'where' command say?
scunacc wrote:
Dear Kervin,
Can you run the sqlite3 under dbx? You may have better luck
getting a backtrace that way instead of reading the core file
after the crash. eg. 'dbx -r
Dear Patrick,
> Could you download 2.8.16 and let us know if your process works with
> that version? If so it may be the same issue and might raise the
> visibility. With the performance improvements I'd much rather be on
> the latest version.
Unfortunately it won't help. The application
I had something similar a while back on a 64bit HPUX box compiled with gcc.
I was getting a core dump / seg fault on big table select when I did
count(*)'s and sum()'s in the query. It wasn't all queries but it was
consist ant and repeatable.
I was able to get the queries to work with SQLite
Dear Christian,
> Doesn't matter how much memory you have. If ulimits restrict how much
> memory a process can have, something has to give. Try:
The process has unlimited ulimits.
Thanks for the suggestion, but other Perl scripts that run already use
huge amounts of memory on this machine, so
On Mon, 1 Aug 2005, scunacc wrote:
>Dear Jay,
>
>> Are you running out of memory?
>
>The machine has 6GB...
>
>I don't think so. It's possible.
>
>Actually, since the query will run with the 64-bit command line version
>I don't *think* so.
>
>Thanks for the thought though.
Doesn't matter how
20 matches
Mail list logo
