[development] Drupal performance patches: call for action
drupal at dwwright.net
Wed Aug 1 23:08:40 UTC 2007
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.
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*
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?
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?
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?
More information about the development