launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Aug 17, 2010 at 4:29 AM, Edwin Grubbs
<edwin.grubbs@xxxxxxxxxxxxx> wrote:
>
> If each request knows whether it needs a read-write or read-only
> database connection so that it can connect to the slave or master,
> couldn't we add the ability for SQLBase to cache all the attributes if
> the request is read-only?

This would be interesting to explore, though I have to confess that my
mind jumped straight to implementation and I saw two considerations
rise up straight away.

Firstly is that caching is only a small benefit itself: it saves us
doing precisely identical work for the life of the cache. However
caching in the model layer is a prerequisite to *prepopulating the
caches*, which is where we get the major wins: that lets us eliminate
repeated similar work by doing one query for a set of data rather than
one query per related thing *per row*. So the gain of caching
everything vs caching what we've figured out is safe is relatively
small, because the incremental gain from both of these things is small
without other work, and that other work will apply to read only and
readwrite transactions.

Secondly, we need to make internal lookups - self.X - cache, to avoid
all db lookups, so we'd need something that can determine whether a
particular attribute is dependent only on DB state (which for a
readonly transaction we can consider immutable) and then cache it, or
whether its dependent on other stuff (like random.random(), for
instance). I don't know if thats even possible without some rather
-too clever- bytecode hacks.

-Rob