InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: InstantDB: InstantDB, the Cassiopeia E-125 & the JVM


Doug

If it's possible to provide a unique, integer based primary key lookup 
then that *might* speed things up. I know I said the type of column 
shouldn't matter, and from the point of view of the lookup it doesn't, 
but from the point of view of selecting rows it could well do.

Integer PKs preserve the order of their target column and so don't have 
to evaluate every row returned by the index. Text and/or multiple 
columns have to get rows back from the index and then evaluate the 
WHERE clause against them.

This is only a theory though, so don't put too much effort into it - it 
might not work.

Pete

----- Original Message -----
From: Doug Robinson <drobinson@zicorp.com>
Date: Tuesday, January 16, 2001 4:34 pm
Subject: InstantDB: InstantDB, the Cassiopeia E-125 & the JVM

> Hello
> 
>    Here I am still working on the same program I asked about last 
> week.
> I have a database with two tables:
> 
>          stmt.executeUpdate ("CREATE TABLE tbl3000 (UC TEXT 
> PRIMARY KEY,
> " +
>                  "Str0 BINARY, type BYTE, Freq INT, basic8
> SHORT)");
>          stmt.executeUpdate ("CREATE INDEX basics ON tbl3000 
> (basic8)");
>        stmt.executeUpdate ("CREATE TABLE ImgCharA (UC TEXT, " +
>                 "ID BYTE, img24x24 BINARY)");
>        stmt.executeUpdate ("CREATE INDEX unicodes ON ImgCharA (UC)");
> 
>    tbl3000 has exactly 3000 records, ImgCharA has about 28000.
> 
>    I have two basic selects:
> 
>        SELECT * FROM tbl3000 WHERE basic8 = "BB" ORDER BY Freq DESC
> 
>    This one "selects" somewhere between 1 an 135 records, takes 2-8
> seconds & I can
> live with that.
> 
>        SELECT img24x24 FROM ImgCharA WHERE UC = "4E2D"  AND ID = 3
> 
>    The UC-ID combination is unique so this select returns only 
> one 72
> byte array. It takes
> somewhere between 5 and 15 seconds. I am hoping to drasticaly 
> reduce this
> some how!!
> 
>    In addition, I have been forced to place a sleep (Thread,sleep
> (100)) before each occurance of
> the second select. If I do not do this I get this error message 
> from the
> JVM:
>    Java Panic
>    Unable to suspend
>    threads, 1024 (more?)
>    times.
> 
> I am desparate! Does anybody know what the error message means or 
> where I
> could find out what it means?
> 
> It may be that the Cassiopeia Pocket PC is just to slow for 
> InstantDB &
> Java, that bad thought now withstanding;
> how can I improve the response with the ImgCharA select.
> 
>    Thanks for your time!
> 
> dkr
> 
> -------------------------------------------------------------------
> ----------
> To unsubscribe from this mailing list, send email to 
> majordomo@enhydra.orgwith the text "unsubscribe instantdb" in the 
> body of the email.
> If you have other questions regarding this mailing list, send 
> email to
> the list admin at owner-instantdb@enhydra.org.
> 

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-instantdb@enhydra.org.