[development] Drupal performance patches: call for action

Larry Garfield larry at garfieldtech.com
Thu Aug 2 05:28:26 UTC 2007

That's the main issue, yes.  The master/slave split is not 1:1 with 
select/[insert|update|delete].  You have to be able to manually control 
whether a select query is "slave safe", which means an API change of one sort 
or another.  A separate function or a flag are the two options.

I'm a decidedly not politically correct person myself, but I'm not a big fan 
of "slave" either.  It is, however, the accurate technical term and I haven't 
come up with a better name yet.

Dries: Sorry to be picky, but did you mean "A period" or "option 1" (A for 
now, B for Drupal 7)? :-)  I really don't like the idea of duplicating every 
query function long-term (meaning every alternate target or additional query 
variant multiples the number of functions we need), although I'm amenable to 
doing so for just one version.  With an all-array structure the clumsy 
argument handling code disappears anyway.

On Wednesday 01 August 2007, mark burdett wrote:
> For functions like node_load, store_transaction_load (ecommerce
> module), etc -- there are times that you load an object and need the
> precise data that was just submitted. and other times you do not.
> If these types of functions are using the slave queries then I guess
> it has to be documented that accurate data just isn't available?
> Unless, there were some parameter to pass in when you need to use the
> master.
> --mark
> On 8/1/07, andrew morton <drewish at katherinehouse.com> wrote:
> > Since d.o is having a fit right now I'll point to the google cache'd
> > version of the issue:
> >
> >ttp://drupal.org/node/147160
> >
> > 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.
> >
> > andrew

Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 

More information about the development mailing list