[development] Drupal performance patches: call for action

[Derek Wright]

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>

If we're going to use a separate query function for queries that can  
be directed to the read-only DB(s), why not call it something like  
"db_query_read()"?  Pardon my ignorance in split DB configurations  
and queries, but are there any read-only queries that aren't safe for  
this?  Don't we just have to direct SELECT queries one way, and  
UPDATE or INSERT queries another?

<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?  Even still, an explicit "db_query_read()" for read-only  
queries you know are safe for secondary DB servers seems the most  
logical to me.  We'd never write to the secondary servers, correct?


Cheers,
-Derek (dww-the-commie-pinko-who's-no-DBA)