RS> On this subject, is there a particular branch that I should be using
RS> for postmodern?
first of all, definitely a version from darcs rather than a 0.9.1 release.
release version has lots of bugs.
as for stable/unstable branches, there shouldn't be a big difference as most
stuff is same an
??>> and taking into account other cursor operations, instead of 3 query
??>> templates we now have something like 12 different queries now, and
??>> i see any pattern how they can be merged :(
??>> or maybe it makes sense to ditch templated query generations and just
??>> write these conditio
ode,
> so not all the transactional magic happens in the persistent heap layer.
> I'm a little fuzzy on exactly how this will work, but it sounds reasonable
> enough.
>
> The DB user would interact mostly with the B-Tree and other indexing
> structures, and with transactions.
>
> and taking into account other cursor operations, instead of 3 query
> templates we now have something like 12 different queries now, and
> i see any pattern how they can be merged :(
> or maybe it makes sense to ditch templated query generations and just write
> these conditions manually
I took
> I am hoping to clarify some of the prior discussions[1] about the native
> Lisp backend for Elephant and propose a basic architecture. Hopefully we
> can modularize development so if somebody wants to hack for a few days on
> the backend he can avoid being overwhelmed.
Glenn Tarcea and me are
> On this subject, is there a particular branch that I should be using
> for postmodern? I've noticed occasional issues where it'll complain
> that a table already exists, generally after a non-elephant error has
> occurred within a transaction.
What branch are you using? 0.9.1, stable or unstabl
I believe the code I attached was scrubbed. Here is a link instead:
http://iodb.org/static/persistent-heap/
Red
On Tue, Oct 28, 2008 at 10:30 AM, Red Daly <[EMAIL PROTECTED]> wrote:
> I am hoping to clarify some of the prior discussions[1] about the native
> Lisp backend for Elephant and propose
I am hoping to clarify some of the prior discussions[1] about the native
Lisp backend for Elephant and propose a basic architecture. Hopefully we
can modularize development so if somebody wants to hack for a few days on
the backend he can avoid being overwhelmed.
Multiprocess support: What featur
LPP> I must've missed something or unintentionally used a db
LPP> with older stuff already in it.
yep, old format database could be the case if you've got it broken
at start.
but it seems our current tests are broken, so you get always get some
error on the first run regardless of backend used.
On this subject, is there a particular branch that I should be using
for postmodern? I've noticed occasional issues where it'll complain
that a table already exists, generally after a non-elephant error has
occurred within a transaction.
Rob
___
elephant
> i've just updated repo elephant-unstable and ran tests with postmodern
> (i have few local changes but i don't think they make difference):
>
> Did 462 checks.
> Pass: 460 (99%)
> Skip: 1 ( 0%)
> Fail: 1 ( 0%)
That's great! :)
I must've missed something or unintentionally used a d
IE> Historically we've had problems with tests being non-idempotent. I
IE> usually wipe the dbs between runs to ensure that hidden interactions
IE> don't break test assumptions.
i have errors in a completely clean environment with a clean store:
Did 455 checks.
Pass: 449 (98%)
Skip:
Historically we've had problems with tests being non-idempotent. I
usually wipe the dbs between runs to ensure that hidden interactions
don't break test assumptions.
Ian
On Oct 28, 2008, at 9:23 AM, Alex Mizrahi wrote:
> LPP> The only major problem with it is that the Postmodern backend
> L
On Tue, Oct 28, 2008 at 12:40:36PM +0100, Leslie P. Polzer wrote:
>
> > Background: Our application that makes heavy use of elephant/bdb and the
> > association feature in the unstable branch is too slow by at least one order
> > of magnitude. We obviously need to profile it first before we start
LPP> The only major problem with it is that the Postmodern backend
LPP> hasn't kept up with the schema evolution changes.
hm, what do you mean? i thought it works reasonably well, as there
are just a handful of glitches to left resolve, but i won't call that "a
major problem".
or am i missing
Unfortunately performance is one thing of several problems that
violate the persistent object abstraction. The first big thing to
sanity check is that a set of operations is wrapped in a transaction.
This avoids disk syncs after every primitive operation which can speed
things up tremendo
LPP> BDB is the fastest backend currently available. Postmodern
LPP> is about half as fast
a little clarification -- it is not like there is a constant slowness
factor.
PostgreSQL storage itself is pretty fast , and probably in some aspects
it is even better than BDB storage.
but there is pret
> Background: Our application that makes heavy use of elephant/bdb and the
> association feature in the unstable branch is too slow by at least one order
> of magnitude. We obviously need to profile it first before we start any
> refactoring or changing the elephant configuration, and most likely
Hi,
I'd like to know if people on the list have experience with the performance
characteristics of the available backends for elephant. I am not asking for
detailed measurements and performance differences of few percent but typical
usage patterns where you can predict that one backend will likely
19 matches
Mail list logo
