??>> elephant reads/writes slots individually, so this means we cannot
??>> have more
??>> than 1000-1 slots operations per second. that sounds quite
??>> prohibitive.
JD> So with an SQL engine this translates to one SELECT/INSERT/UPDATE per
JD> slot value read or write?
something like
On Thu, Feb 21, 2008 at 3:35 PM, John DeSoi <[EMAIL PROTECTED]> wrote:
>
> On Feb 21, 2008, at 6:12 AM, Alex Mizrahi wrote:
>
> > elephant reads/writes slots individually, so this means we cannot
> > have more
> > than 1000-1 slots operations per second. that sounds quite
> > prohibitive.
On Feb 21, 2008, at 6:12 AM, Alex Mizrahi wrote:
elephant reads/writes slots individually, so this means we cannot
have more
than 1000-1 slots operations per second. that sounds quite
prohibitive.
So with an SQL engine this translates to one SELECT/INSERT/UPDATE per
slot value read o
IE> Is this caching something that we could import into BDB?
it is pretty easy to add caching inside one transaction or accross
transactions assuming there is only one instance (and one thread) working
with database. we can have this part implemented in the core and shared
among backends..
ca
the solution seems to be trivial: implement caching on a client
side. simple
solution is to cache data within single transaction. complex
solution is to
cache data accross transaction, tracking changes and invalidating
stale
cache entries automatically.
we've implemented both options. so no
> So, putting licensing issues aside, what is the real difference/ advantage
> of one data store over the other? In a recent email I read by Alex, he
> mentions he's going to work on improving performance on the postmodern
> data store. So, even after that improves and performance is matched
