* sub sk:
> Somehow no one seems to have mentioned it on this mailing list so far!?
> Here is the scoop...
>
> On March 23, Oracle announced the latest release of Oracle® Berkeley
> DB - 11g Release 2 - which introduces a new SQL API, based on lo and
> behold, SQLite v3 API. What this means is
On 4/1/10 4:12 , "Neville Franks" wrote:
> Thursday, April 1, 2010, 12:16:13 PM, you wrote:
>
> JJD> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
> JJD> wrote:
There were many problems with
that approach:
>>> ...
(3) Each
On Wed, Mar 31, 2010 at 06:16:13PM -0700, Jim "Jed" Dodgen wrote:
> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
> >> (3) Each table and index is in a
> >> separate file so your "database" was a directory full of files instead
> >> of a single file
> >
> > This one is not a problem. Actually I
Thursday, April 1, 2010, 12:16:13 PM, you wrote:
JJD> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
JJD> wrote:
>>> There were many problems with
>>> that approach:
>> ...
>>> (3) Each table and index is in a
>>> separate file so your "database" was a directory
On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
wrote:
>> There were many problems with
>> that approach:
> ...
>> (3) Each table and index is in a
>> separate file so your "database" was a directory full of files instead
>> of a single file
>
> This one is not a
> There were many problems with
> that approach:
...
> (3) Each table and index is in a
> separate file so your "database" was a directory full of files instead
> of a single file
This one is not a problem. Actually I don't see how 1 file is better
than 1 directory. For example mac
Hello!
On Monday 29 March 2010 22:26:41 D. Richard Hipp wrote:
> I can come up with additional reasons why replacing the existing
> SQLite backend with TC is not a good idea, but perhaps the above will
> suffice.
But how about insert/update performance on big indices? When index size
is more
On Mar 29, 2010, at 1:56 PM, Alexey Pechnikov wrote:
> Hello!
>
> On Monday 29 March 2010 20:22:36 D. Richard Hipp wrote:
>> SQLite version 1 used gdbm for storage. There were many problems
>> with
>> that approach: (1) gdbm is a hash-based system so it could not do
>> range queries (2) gdbm
Hello!
On Monday 29 March 2010 20:22:36 D. Richard Hipp wrote:
> SQLite version 1 used gdbm for storage. There were many problems with
> that approach: (1) gdbm is a hash-based system so it could not do
> range queries (2) gdbm is GPL, (3) Each table and index is in a
> separate file so
On Mar 29, 2010, at 12:03 PM, Jay A. Kreibich wrote:
> On Mon, Mar 29, 2010 at 09:15:45AM +0530, Roger Binns scratched on
> the wall:
>
>> I believe the btree/paging layer is replaced with BDB.
>
> Didn't SQLite "1" use a dbm library for the storage layer?
>
> The more things change
>
On Mon, Mar 29, 2010 at 09:15:45AM +0530, Roger Binns scratched on the wall:
> I believe the btree/paging layer is replaced with BDB.
Didn't SQLite "1" use a dbm library for the storage layer?
The more things change
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Our
On Mon, Mar 29, 2010 at 3:23 AM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> P Kishor wrote:
>> thanks for the clarification, but how does the above statement
>> reconcile with "the btree/paging layer is replaced with BDB"? Does
>> that refer to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P Kishor wrote:
> thanks for the clarification, but how does the above statement
> reconcile with "the btree/paging layer is replaced with BDB"? Does
> that refer to a different version of SQLite being offered by Oracle
> that includes BDB for
2010/3/29 P Kishor :
> On Sun, Mar 28, 2010 at 10:50 PM, Dan Kennedy wrote:
>>
>> On Mar 29, 2010, at 10:48 AM, P Kishor wrote:
>>
>>> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns
>>> wrote:
-BEGIN PGP SIGNED
On Sun, Mar 28, 2010 at 10:50 PM, Dan Kennedy wrote:
>
> On Mar 29, 2010, at 10:48 AM, P Kishor wrote:
>
>> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> sub sk79 wrote:
How
2010/3/29 Roger Binns :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> sub sk79 wrote:
>> How So? Is SQLite getting a high concurrency module from BDB in
>> exchange for its SQL API?
>
> I believe the btree/paging layer is replaced with BDB.
>
Confirmed.
On Mar 29, 2010, at 10:48 AM, P Kishor wrote:
> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> sub sk79 wrote:
>>> How So? Is SQLite getting a high concurrency module from BDB in
>>> exchange for its SQL
On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> sub sk79 wrote:
>> How So? Is SQLite getting a high concurrency module from BDB in
>> exchange for its SQL API?
>
> I believe the btree/paging layer is replaced with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sub sk79 wrote:
> How So? Is SQLite getting a high concurrency module from BDB in
> exchange for its SQL API?
I believe the btree/paging layer is replaced with BDB.
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using
On Sun, 28 Mar 2010 14:59:15 -0400, sub sk79
wrote:
>Hi,
>
>Somehow no one seems to have mentioned it on this mailing list so far!?
>Here is the scoop...
>
>On March 23, Oracle announced the latest release of Oracle® Berkeley
>DB - 11g Release 2 - which introduces a new SQL
20 matches
Mail list logo