Thanks for the advice. I agree with you that QDBM support is probably not
justified at this point.
Regards,
Rangarajan
- Original Message -
From: "Ian Eslick" <[EMAIL PROTECTED]>
To: "Elephant bugs and development"
Sent: Friday, February 15, 2008 7:47 PM
Subject: Re: [elephant-devel]
For now, SQLite3 is the best way to avoid royalties and have an easily
deployable solution. As Alex said, given the way we are using the SQL
engine to store data, the performance isn't so great compared to BDB
because we're simulating BTrees on top of SQL. If you want a direct
map to a SQ
OK, I think I have applied those patches correctly.
Perhaps you could do a "darcs pull" or a "darcs diff" against the repo
to make sure I did it correctly; I still find darcs a little confusing,
and my private repo was not in sync with the offical one.
However, I was green with your changes in my
On Fri, 2008-02-15 at 10:29 +0100, Henrik Hjelte wrote:
> On Fri, Feb 15, 2008 at 9:10 AM, Alex Mizrahi <[EMAIL PROTECTED]> wrote:
> > i think it doesn't have sence to apply them now, though -- Henrik already
> > has updated patches that work better (that famous instances
> > reinitialization
>
RLR> I think SQLite is faster than PostGres on our test suite. It is my
RLR> understanding that this is perhaps possible because it provides much
RLR> weaker concurrency control.
i don't think concurrency control is in effect here. on postgresql side all
is very fast!
PostgreSQL could be slo
JD> hassles. I don't really know anything about BDB, but I'm surprised the
JD> performance of a properly indexed SQL database can't get close to it.
BDB works directly with files, but SQL backend working with PostgreSQL or
database like this needs to send queries over network -- that has
signi
