[development] Drupal performance patches: call for action

andrew morton drewish at katherinehouse.com
Wed Aug 1 23:24:00 UTC 2007

Since d.o is having a fit right now I'll point to the google cache'd
version of the issue:

As long as it is I'd suggest reading through that, David Strauss
pretty much gave a lecture and took notes for us ;)

On 8/1/07, Derek Wright <drupal at dwwright.net> wrote:
> On Aug 1, 2007, at 3:50 PM, andrew morton wrote:
> > I'd prefer to use db_query_slave(). It makes it simple to direct safe
> > queries to the slave with a minimum of changes.
> <politically_correct type="proud">
> Am I the only one who recoils at the usage of the word "slave" for
> this?  Do we really have to let that word get all the way into the
> Drupal core API itself? :(  While I'm sure some of the people on this
> list would think it's funny, no one in their right mind would call
> this "db_query_bitch()", either, even though to some, it'd have
> basically the same meaning.  *sigh*
> </politically_correct>

In #60 Crell also expresses some reservations about the naming.
Personally I don't think it's a big deal but maybe that's because I
grew up setting master/slave jumpers on IDE drives.

> <idea type="crazy">
> Can't we just parse the query and see if it contains any UPDATE or
> INSERT clauses? ;)  Why do we need to change the API at all?
> </idea>
> I suppose the problem is queries that SELECT to check a value and
> then update it, and you'd want to do both of those on the primary
> DB.  That's why we either need transaction awareness, or we need the
> query author to specify what they need explicitly.  Is that the
> issue?

Yeah, in #3 David Strauss discusses the problems with auto detection,
basically there's some lag between when you write something and when
it's propagated to the slave. If it's important that the query reflect
recent changes you need to query the master. When you don't care, you
can query a slave.


More information about the development mailing list