[development] Drupal performance patches: call for action

mark burdett mfburdett at gmail.com
Thu Aug 2 00:11:18 UTC 2007


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:
> http://72.14.253.104/search?q=cache:QZEkIeazljEJ:drupal.org/node/147160+http://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
>


More information about the development mailing list