On Monday, 22 February 2016 at 03:33:27 UTC, Chris Wright wrote:
> On Sun, 21 Feb 2016 21:15:01 +0000, Stefan Koch wrote:
>
>> On Sunday, 21 February 2016 at 19:55:38 UTC, Any wrote:
>>> On Sunday, 21 February 2016 at 19:21:31 UTC, Stefan Koch wrote:
>>>> where n is the number of rows.
>>>
>>> That means your doing a full table scan. When the table gets large enough, this gets problematic.
>> 
>> When the table get's large enough you probably don't worry about CTFE'ing it anymore.
>
> So you intend this to work *only* at compile time? Or would you supply a different API for querying at runtime?

I intend to have a D-style SQLite compatible Database solution. However I will not reinvent MySql or postgres. Performance is important to me. Scaling to bigger Data however is secondary at this point.

Another small update.

So far ldc has the lead in my performance test
ldc2 produces significantly faster results then gdc or dmd.
I will have a look at the IR and see how I can "port" the optimisations it does to the sourceCode.

On Monday, 22 February 2016 at 14:11:46 UTC, Stefan Koch wrote:
> Another small update.
>
> So far ldc has the lead in my performance test
> ldc2 produces significantly faster results then gdc or dmd.
> I will have a look at the IR and see how I can "port" the optimisations it does to the sourceCode.

After rewriting the engine to allocate less gc memory, gdc is faster then ldc again.

- In a slightly unfair benchmark I had an 3.5x performance advantage over sqlite.
  (unfair, because I don't parse SQL and just extract the colums raw)
   yet at the and of the day, this is how SQLite is meant to be used.
   As a convenient data-storage.
more news :

Write support is coming!
After that is finished let's see by how much I can beat sqlite dong bulk inserts.

On Friday, 26 February 2016 at 09:53:46 UTC, Stefan Koch wrote:

> Write support is coming!
> After that is finished let's see by how much I can beat sqlite dong bulk inserts.

dong => doing.

- anyone who wants to help bench-marking please write me.
uplink DOT coder AT gmail C O M

Another update :
Performance is now 3 times better then with my initial version.

Tip of the Day  : constantly reevaluate your design-decisions.

On Monday, 22 February 2016 at 03:39:57 UTC, Stefan Koch wrote:
> On Monday, 22 February 2016 at 03:33:27 UTC, Chris Wright wrote:
>> On Sun, 21 Feb 2016 21:15:01 +0000, Stefan Koch wrote:
>>
>>> On Sunday, 21 February 2016 at 19:55:38 UTC, Any wrote:
>>>> On Sunday, 21 February 2016 at 19:21:31 UTC, Stefan Koch wrote:
>>>>> where n is the number of rows.
>>>>
>>>> That means your doing a full table scan. When the table gets large enough, this gets problematic.
>>> 
>>> When the table get's large enough you probably don't worry about CTFE'ing it anymore.
>>
>> So you intend this to work *only* at compile time? Or would you supply a different API for querying at runtime?
>
> I intend to have a D-style SQLite compatible Database solution. However I will not reinvent MySql or postgres. Performance is important to me. Scaling to bigger Data however is secondary at this point.

Great project, Stefan.  Any idea what kind of maximum database size will be feasible ?  I realise it is early days so far and not your main focus.

Laeeth

On Sunday, 28 February 2016 at 01:45:48 UTC, Laeeth Isharc wrote:
> Great project, Stefan.  Any idea what kind of maximum database size will be feasible ?  I realise it is early days so far and not your main focus.
>
> Laeeth

The limits will be almost the same as in sqlite.
So a few 100TB

On Sunday, 28 February 2016 at 01:55:50 UTC, Stefan Koch wrote:
> On Sunday, 28 February 2016 at 01:45:48 UTC, Laeeth Isharc wrote:
>> Great project, Stefan.  Any idea what kind of maximum database size will be feasible ?  I realise it is early days so far and not your main focus.
>>
>> Laeeth
>
> The limits will be almost the same as in sqlite.
> So a few 100TB

nice.  and thanks.  Laeeth.