Mark Parker-4 wrote:
> This isn't an "SSD". It's connected directly to the PCI Express bus, and
> "low cost" it certainly is NOT. It's much more valuable than the server
> it's plugged into.
Check page size. It might be less than cluster of your ioExtreme. You should
also think about actually
Alexander Kitaev-3 wrote:
>
> We're glad to announce that SQLJet 1.0.0 has been released and available
> for download at http://sqljet.com/ web site.
>
Hi.
Several questions:
1. Are there any real reasons for having dual-licensed commercial partial
reimplementation of SQLite in Java? Any
souvik.datta wrote:
> Update set Flag=1 where Filename=;
Check index presence on Filename column and still make updates in 1 large
transaction.
-
Best Regards.
Max Kosenko.
--
View this message in context:
http://www.nabble.com/Making-Update-fast-tp25269409p25273296.html
Sent from the
danjenkins wrote:
>
> Hello,
> We use a julian.decimal format to represent date/time (i.e. noon of August
> 26, 2009 would be 40049.5000) and we use this julian date for an index
> key. Our databases are frequently up to 3GB in size containing 10 million
> records with 15 assorted field types
Noah Hart wrote:
> C#-SQLite is now ready for review. The project is located at
> http://code.google.com/p/csharp-sqlite
I think this name much better than sql-sharp.
I've posted a question on SQLite ADO.NET forum
http://sqlite.phxsoftware.com/forums/p/1879/7971.aspx about supporting your
I need to apologize once again. Slow deletes explained as bug in SQLite tests
and flags of Perst compilation. Now they both head to head on basic ops with
2x on Perst selects (can be due to the ADO reader instantiations)
http://www.nabble.com/file/p24795746/TestIndex.cs TestIndex.cs
SQLITE
I need to apologize once again. Slow deletes explained as bug in SQLite tests
and flags of Perst compilation. Now they both head to head on basic ops with
2x on Perst selects (can be due to the ADO reader instantiations)
http://www.nabble.com/file/p24795731/TestIndex.cs TestIndex.cs
SQLITE
Sorry, test bug in SQLite select test.
http://www.nabble.com/file/p24789308/TestIndex.cs TestIndex.cs
index searches:
20: SQLITE 8.1635400 PERST 3.3406065
200: SQLITE 1:10.6331745 PERST 54.9915975
-
Best Regards.
Max Kosenko.
--
View this message in context:
Dan Kennedy-4 wrote:
> Earlier I just quoted the conclusions of the McObject report. Maybe I
> misunderstood. But now that I have read the benchmark code, I'm curious.
> Why is the SQL not being recompiled for each query? Is there some kind of
> compiled query cache hiding behind the
Dan Kennedy-4 wrote:
> Are you by any chance the author of the report I'm reading?
I'm not an author of test or McObject staff/representative at all. But I can
give a link to this forum to author (still insisting that this is offtopic
here) to answer himself.
-
Best Regards.
Max Kosenko.
--
Dan Kennedy-4 wrote:
> McObject CEO Steve Graves points out that because of limits of the API
> they were using, SQLite performs each INSERT and DELETE in the test in a
> separate transaction. So the reported times for these tests may be more of
> a measure of the speed of the media than SQLite
John Stanton-3 wrote:
>
> Maybe the author could explain the reason for C# translation. Surely a
> better approach if the JIT is required would be to use something like
> gcc and change the code generator to the C# metacode. Such a product
> may already exist.
>
> A translated program is
Noah Hart wrote:
> The license is the same as SQLite, I'm waiting on google to change the
> project to PD since that is not one of the canned choices.
Thank you very much.
Can't disagree with Miguel that this is "A godsend gift to developers".
Keep us informed about name change (in case Dr.
Seems like I've missed something...
Well, if there would be a team dedicated to supporting managed
implementation of SQLite which can be at any time quickly updated to reflect
all changes of SQLite native - anyone can always transfer such requests to
that team. Same happens i.e. with SQLite.NET
It's a pity news. I hoped Dr. can think about even somehow supporting your
project.
I don't know why he insists on that (he actually can answer for himself
here) while there are a lot of SQLite based projects with that name usage.
May be that's because of your license?
Max.
Noah Hart wrote:
>
> Current results ...
> 9 errors out of 30054 tests
>
> Still skipping about 9 additional tests
>
> Noah
>
> Kosenko Max wrote:
>>
>> Wow, that's impressive.
>>
>> And very interesting that you've gained 3x-5x performance gain.
>>
>
>>
>> Hummm... Guess there is a reason there are no implementations of C#
>> external
>> to the Mickeysoft world :-)
>>
>> Guess if I had a lot of time to kill I could port it to Delphi...
>>
>> BTW, what's the memory footprint?
>>
>> Fred
>>
Fred Williams wrote:
> Hummm... Guess there is a reason there are no implementations of C#
> external to the Mickeysoft world :-)
One of the reason is true multiplatform support with Mono for managed world.
Another one is Silverlight DB.
-
Best Regards.
Max Kosenko.
--
View this
.
Cory Nelson wrote:
>
> On Sat, Aug 1, 2009 at 4:21 AM, Kosenko Max<kosenko@vyzo.com> wrote:
>>
>> Seems like I've misunderstood your performance results. And they are
>> 3-5times
>> slower than original...
>>
>
> This could be for a number of re
Seems like I've misunderstood your performance results. And they are 3-5times
slower than original...
-
Best Regards.
Max Kosenko.
--
View this message in context:
http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24768252.html
Sent from the SQLite mailing list archive at
Wow, that's impressive.
And very interesting that you've gained 3x-5x performance gain.
Don't make this project educational only. I'm sure you'll find additional
contributors. Just recently Miguel de Icaza was asking for line by line port
of SQLite to C#.
Great achievement that all tests are
You're talking about db size much less than 1 billion records.
In 1 billion records db with described scenario cache hit ratio so small
that everything you're talking about just very close to zero difference in
effect. Because 1 uncached random IO operation is 10ms. Any reasonable
calculations
Expenses in B-Tree not in the node splitting (that is really not that often
and takes small amount of time). As I've said - it's in finding right place
to insert.
Root level which takes 1 page will do the same as your hash index. And will
use much less space in cache. This root page in such DB
Well, I understand idea in general and how it works. But as you have
described in second part of your letter - this won't help. Even if you will
create 100 tables that will save you just 1 step from 5-7 IO steps, but
won't make Cache hit ratio significantly higher. And I'm pretty sure that
even
Doug Fajardo wrote:
> No, I admit I haven't tried this under SQLITE.
>
> Whether this approach will help for the specific application will depend
> on data usage patterns, which we haven't delved into for this application.
> Call me simple: since the main issue is degraded performance with
John Stanton-3 wrote:
> Why would it not work? It is just adding an extra top level to the
> index. A tried and true method.
It will work. But won't give performance benefit. And from my undestanding
it will even slow down things.
You can place parts of index in different DB and on different
I forgot to say about hash...
My personal choice will be MurmurHash2 64 bit function
http://murmurhash.googlepages.com/
http://en.wikipedia.org/wiki/MurmurHash2 - lots of implementations here
It's fast (even in managed impls), have good characteristics and free.
Don't use CRC64...
P.S. You
Matthew O'Keefe wrote:
> We wanted to post to the mailing list to see if there are any obvious,
> first-order things we can try to improve performance for such a large
> table.
The problem with slow inserts generally speaking lies in the problem of
cache miss.
Imagine that each new insert in
Have you ever tested such proposal?
I believe that doesn't works.
Doug Fajardo wrote:
>
> One approach might be to split the big, monolithic table into some number
> of hash buckets, where each 'bucket' is separate table. When doing a
> search, the program calculates the hash and accesses
Ribeiro, Glauber wrote:
> If it's all reads, you're fine, but if anyone is writing, all others are
> blocked until that transaction is finished.
And actually SQLite can't read at the exactly same time in several threads
in case it's compiled as a thread safe.
--
View this message in context:
Michael Sync wrote:
>
> Is there any way to support SQLLite in Silverlight? Let's say I have a
> SQLLite database in Isolated Storage and want to connect that database
> from
> Silverlight without using any service.
>
> Do we need to create our own database driver? I'm also a developer but I'm
gerpux wrote:
>
> I've heard that the guys at db4o said that, under certain
> circunstances, db4o is 500x faster than sqlite:
> Is this because of the jdbc driver?
> What would be a more realistic measure? (db4o is an object database,
> not a relational one)
> They are using the poleposition
32 matches
Mail list logo
